Proposal: TimeSpan literals

[jodydonetti]

Intro: ubiquitous and rock solid

There's a common value type that has become ubiquitous when working with anything from database calls, network calls, rest/graphql apis, caches, delays, timeouts and so on: TimeSpan.

This type is used in a way or another everywhere in the .net ecosystem, both internally in the runtime/BCL and externally in almost any library.

Not only it is ubiquitous, it also stood the test of time without any reasonable change.

With DateTime there has been historically a need for a better representation, so we saw the rise of DateTimeOffset and libraries like Noda Time with types like LocalDateTime, OffsetDateTime and ZonedDateTime.

With TimeSpan instead, that is not the case: apart from some minor extensions and internal optimizations (which would still be possible anyway), nothing changed.

Nitpicking corner: yes, in Noda Time there's the Duration type, but that is not as needed as the DateTime alternatives and it's "just" a bigger TimeSpan, allowing greater slices of time.

Problem

So, the issue I'm highlighting here is that initializing a TimeSpan takes longer than probably needed in terms of characters that need to be typed, and later read.

Some examples:

await Task.Delay(TimeSpan.FromMilliseconds(100));

await _repo.ExecuteAsync("UPDATE Foo ...", timeout: TimeSpan.FromSeconds(5));

await _cache.Set("foo", 123, duration: TimeSpan.FromMinutes(10));

await _cache.GetOrSet(
  "product:123",
  async ct => GetFromDb(123, ct),
  options => options.SetDuration(TimeSpan.FromMinutes(10)).SetFactoryTimeouts(TimeSpan.FromMilliseconds(100), TimeSpan.FromSeconds(1))
);

As can be seen, a big chunk of the space on each line is taken by the TimeSpans initialization: considering again how ubiquitous TimeSpans have become, each time we write or read them there's somewhat of a waste, and this seems like a good opportunity for a potential improvement.

Considerations about time

Any discussion about time should begin by referring to the common falsehoods involved: local vs UTC, dates in the past vs in the future, and in general timezones are a notoriously complex subject with a lot of details to get right and traps difficult to avoid.

In this case though we are talking about timespans, and in this regard they are an exception since they are "pure".
As an example "42 seconds are 42 seconds are 42 seconds", so to speak, and unless we talk about more complex units like a week or a month (which should be probably avoided), there are no issues involved, and each value cannot be misinterpreted.

Proposal

This proposal is about adding some of the common units as suffixes usable in the literal syntax.

For how specifically, please see the 2 proposals below.

Proposal 1: normal suffixes

The first proposal is about adding the common units, specifically:

• us (microseconds)
• ms (milliseconds)
• s (seconds)
• min (minutes)
• h (hours)

I explicitely excluded d for days, even though in the TimeSpan type there is the FromDays(...) static method, because I'm thinking about things like daylight savings etc, which may confuse some cases of what "a full day" means since a "full day" sometimes may be 23h long or 25h long, on top of the canonical 24h.
Having said that, theoretically the same can be said about "a full hour" in the case of a leap second, so by explicitely defining these units as their canonical version we can simply avoid all this problems and use even days without any issue (and, btw, this is already what happens when using the FromDays(...) method).

Another missing unit here is nanoseconds (ns): this can be easily added, theoretically, but practically the TimeSpan works with ticks which have a resolution of 100ns: the TimeSpan type in fact - at least in recent versions of .NET - has a Nanoseconds property (and a TotalNanoseconds() method) but they are get-only, since setting a value that would be automatically rounded or truncated is something risky and counter-intuitive.
Because of this I would suggest not adding ns support, at least for now.

The same abbreviations are already used by the known chrono API, so another point to consider.

The previous example would then become:

await Task.Delay(100ms);

await _repo.ExecuteAsync("UPDATE Foo ...", timeout: 5s);

await _cache.Set("foo", 123, duration: 10min);

await _cache.GetOrSet(
  "product:123",
  async ct => GetFromDb(123, ct),
  options => options.SetDuration(10min).SetFactoryTimeouts(100ms, 1s)
);

Something to note is that although we can theoretically pick either s or sec for seconds (although in the SI uses s so I would stick with that), we cannot use either m or min for minutes, since m is already used for the Decimal type.

This problem can be summarized as the known "global namespace pollution" already seen multiple times in different areas, the most famous of which is probably the one in the JS world, where multiple scripts injected in a page may generate collisions in the global namespace by declaring different variables with the same name at the global level.

The problem here is similar, although not the same, since the .NET team is the one who controls what literal suffixes (or prefixes, like with the binary notation) are added: having said that, the idea of not risking future collisions and allowing for more extensibility is something that may be useful to at least talk about, even though it may not be used.

Proposal 2 tries to branistorm this.

Proposal 2: suffix family (a.k.a. namespacing)

Instead of adding new suffixes directly in the global literal suffix namespace, an idea may be to add the concept of a literal suffix namespace or family, where t may represent the one related to "time": in this way it would be possible to avoid collisions by virtue of using a grouping prefix.

A possible syntax may be "{family}:{unit}", to get something like:

• t:us (microseconds)
• t:ms (milliseconds)
• t:s (seconds)
• t:min (minutes)
• t:h (hours)

With this approach the only suffix "consumed" in the global suffix namespace would be t, leaving the room for others to be added in the future without creating collisions.

This approach is more complex than the previous one (and maybe overkill), but is something to at least think about, imho.

The previous example would then become:

await Task.Delay(100t:ms);

await _repo.ExecuteAsync("UPDATE Foo ...", timeout: 5t:s);

await _cache.Set("foo", 123, duration: 10t:min);

await _cache.GetOrSet(
  "product:123",
  async ct => GetFromDb(123, ct),
  options => options.SetDuration(10t:min).SetFactoryTimeouts(100t:ms, 1t:s)
);

Time in general and the TimeSpan type in particular are so core that we may even bite the bullet, consume some entries in the global namespace, and go without the family prefix: not sure about that, leaving this to the discussion that may emerge from this.

Parsing/Formatting

In case this will be done, support for parsing/formatting should also be added to "close the loop".

I'm thinking about something like this:

var duration = TimeSpan.Parse("5min");

var delay = TimeSpan.Parse("10s");

var foo = TimeSpan.Parse("1ms");

This would also be usable in config files (typically JSON, like appsettings) so that the intent would be clearer, imho.

On the formatting side, maybe some Custom Format Strings can also be created to express "total units", for example with "ts" (total seconds), "tus" (total microseconds), "tmin" (total minutes) and so on.
With this, a timespan of "1 minute and 50 seconds" can be formatted with a "ts" format as "110s".

On top of this, a new Standard Format String may be created, like "wu" (whole units), that would automatically use the biggest possible whole unit.
An example can be a timespan of "10 seconds" which can be formatted as "10s", whereas one of "120 seconds" would be formatted as "2min".

Still not sure about these to be honest, since more brainstorming should be put into all the details and corner cases, like what should happen when the total value is fractional? Probably there's some more reasoning to be made about fractional values and formats, but this is a starting point.

Alternatives

The usual alternative suggested is to just use some extension methods on ints (like 42.Seconds()), either from already existing libraries (like Humanizer, probably the most famous) or by rolling our own.

The main problem with this approach is that working with TimeSpan is so ubiquitous that having to do either of those things in each and every project seems really overkill.
Being forced to use a library for such a small and core need also creates a dependency on a 3rd party project which, as seen in the Humanizer case, can then become somewhat abandoned and not a solid solution (meanwhile the Humanizer project seems to be getting back on track, to be fair).

On top of this, creating such wide ext methods on core types like int has always been discouraged by the .NET team, if I remember correctly.

Also, such approaches do not allow for a wider usage (see parsing/formatting above), and would not be usable in tutorials, samples, blog posts, etc and that would reduce the advantages of a native approach.

Finally, all calls would then be an additional method call, so by doing 42.Seconds() the calls would actually be 42.Seconds() -> TimeSpan.FromSeconds(42) -> new TimeSpan(...) etc.

Possible optimization?

I didn't want to create a separate discussion for this (yet), but while we are here: since a TimeSpan in the end is stored in a ticks field of type long, for which there's also a directly accessible ctor new TimeSpan(long), and since any possible calculation of "seconds to ticks" or "minutes tu ticks" would be just a "calculatable const" wouldn't it be possible to generate at compile time a lowered C# which is directly that?

What I mean is that any call with a constant input value like var foo = TimeSpan.FromMilliseconds(123) could be automatically lowered to var foo = new TimeSpan(1230000), I think, which is what is being done internally inside the FromMilliseconds(...) method anyway.

Looking at the code I see that in some of the ctors and static methods there are some extra checks for min/max values, but the same is not there in the basic new TimeSpan(ticks) one, which seems strange.

Am I missing something?

In case this makes sense I can open a separate discussion or issue for that.

🔔 Update 2024-03-04

A lot of comments pointed out about a more generic "user defined literals" feature: although I feel it can be something useful to think about, I also have mixed feelings about the practicality of it all things considered. I think it's something that should be discussed, but not necessarily implemented right away since that would take most probably years to get to something, if at all.

A nice balance would be to pick a TimeSpan syntax that would be compatible with an hypothetical extension in the future, and doesn't clash with that is alrady there (my Proposal 1 I think follows these principles).

Because of this and more, I'd like to keep this proposal only for the very specific case of the TimeSpan type, because I think it is "different", it has a special place in .net as a whole and therefore may deserves a special treatment.

To summarize in a single place:

• it is core to the framework itself, being there since the beginning
• time is the only unit of measure already naturally present in the framework, as @TahirAhmadov also pointed out
• it has a lot restrictions by nature
• in 20+ years not one of the time-related suffixes have been already used by some other types, which "fits nicely" and doesn't cause problems
• it is in the particular position of, as of today, not having any more units left to address in the future
• it is singularly culture invariant, without different units for different cultures (unlike meters vs feet, liters vs gallons, etc)
• the space saving visually would be not so small (imho): TimeSpan.FromMilliseconds(42) vs 42ms

[HaloFour]

Doesn't feel really necessary given you could always write static helper methods that are as terse as you desire and use them throughout your project.

var ts = secs(5);

You could make them function more like literal suffixes via extension methods:

var ts = 5.sec();

And, with extension everything, that could be further reduced to property syntax:

var ts = 5.sec;

I expect the "suffix namespacing" component of your proposal would run into parsing issues with ternary conditional expressions.

[tannergooding]

This is definitely an area for the runtime team to look into. Ideally, K() and J() should be identical in the final JITted assembly.

Some of the complexities here come from the underlying algorithm having to take in an arbitrary double.

Because the algorithm must be general purpose, it has to do things like check for double.NaN, it then has to scale from the unit given (500ms) to ticks. Since there are 10,000 TicksPerMillisecond, this means we multiply to get 5,000,000 Ticks. That then has to undergo bounds checks to ensure it is within the realm of valid values accounting for the fact that not all Int64 can be exactly represented by double.

All of this first work is what happens for TimeSpan.FromMilliseconds and it happens as part of inlining, constant folding, eliminating dead code, and generally handling around 6 different calls.

After that it has to resolve TotalMilliseconds which means it has to resolve the implicit ref TimeSpan parameter (representing this) and so it has to work past the value being "address exposed". It then has to resolve a conversion of the underlying tick amount to double, a division by TicksPerMillisecond (which could potentially produce inaccuracies), do some additional comparisons to account for boundary values, and then cast that result back to an int.

So the amount of logic actually required to handle what you've written here is pretty complex and has several scenarios where very subtle things can end up breaking the JITs ability to optimize, whether it be caused by using up too much inlining budget, to encountering a potential NaN, or other value it can't process.

In .NET 8, it actually optimizes this anyways down to the following:

; Method C:K() (FullOpts)
G_M000_IG01:                ;; offset=0x0000
       sub      rsp, 40
       vzeroupper 

G_M000_IG02:                ;; offset=0x0007
       vmovsd   xmm0, qword ptr [reloc @RWD00]
       vcvttsd2si  ecx, xmm0
       call     [System.Console:Write(int)]
       nop      

G_M000_IG03:                ;; offset=0x001A
       add      rsp, 40
       ret      
RWD00  	dq	407F400000000000h	;          500
; Total bytes of code: 31

In the latest nightly builds of .NET 9, it is able to get it down to

; Method C:K() (FullOpts)
G_M19241_IG01:  ;; offset=0x0000
       sub      rsp, 40
						;; size=4 bbWeight=1 PerfScore 0.25

G_M19241_IG02:  ;; offset=0x0004
       mov      ecx, 500
       call     [System.Console:Write(int)]
       nop      
						;; size=12 bbWeight=1 PerfScore 3.50

G_M19241_IG03:  ;; offset=0x0010
       add      rsp, 40
       ret      
						;; size=5 bbWeight=1 PerfScore 1.25
; Total bytes of code: 21

So it still does the right thing, unlike what SharpLab is showing, but the amount of cost and chance for things to subtly go wrong is pretty immense such that the optimization can't be guaranteed. Ultimately because this conversion is non trivial

[TahirAhmadov]

@tannergooding thanks a lot for the provided information! Yes I understand it's not "trivial", and I'm pleasantly surprised that latest runtimes do a better job than what SharpLab shows.

We don't get rid of APIs, they will stick around essentially forever.

That's the thing - what if at some point in the future the optimizations you demonstrated are "reliable" and there is no performance reason to call the int ms overloads - do you see the value of standardizing on the TimeSpan ts overloads, for type safety and readability reasons? (Even if it means writing something like 123.ms() and not 123ms.)

[TahirAhmadov]

Users may end up wanting to represent things like x hours, y seconds, z milliseconds, ... (and there have been clear requests for that in this same discussion) and so simply 5ms may not be enough.

I'm not sure what that means. Who asked for it? How can that even work in C# with spaces? I'm confused.
My understand was that it would be 1hr + 2sec + 3ms.

[tannergooding]

what if at some point in the future the optimizations you demonstrated are "reliable" and there is no performance reason to call the int ms overloads

Then removing the APIs would break backwards compatibility. Breaking binary back compat is a bar we almost never cross, because it hurts the ecosystem for very little benefit.

The APIs also still ultimately puts more strain on the JIT to do optimizations as well, so even as we improve things more, it still ends up taking more budget, more startup cycle time, and ends up having some very minor considerations that the other APIs don't have. Such APIs may end up having to do more computation to account for other inputs (sub ms or very large times) as well, disallowing them from properly reaching the same perf in practice.

do you see the value of standardizing on the TimeSpan ts overloads, for type safety and readability reasons? (Even if it means writing something like 123.ms() and not 123ms.)

Not personally. A lot of the callsites where its taken are fairly obvious that the value is a timeout and there are many ways to improve readability for these scenarios without needing a whole new language feature. Users can always enforce themselves using the TimeSpan overload or provide convenience extensions (allowing 123.ms()) if they felt that was beneficial for them.

I'm not sure what that means. Who asked for it? How can that even work in C# with spaces?

It was more descriptive text, indicating users have asked or suggested for ways to allow specifying multiple units at once. Much as 11:23:59 is a way to represent hours:minutes:seconds.

If the language were to do this, it could come down to 11hr + 23min + 59sec or similar, but that's yet another design-point and consideration that has to be taken into account.

[jodydonetti]

Hi @tannergooding , thanks for your time answering this, it is a treasure trove of insightful details.

Up through and including .NET 8, TimeSpan has exposed APIs for parsing from and formatting to a string. These are precise, but have several different potential input formats users end up having. Users may end up wanting to represent things like x hours, y seconds, z milliseconds, ... (and there have been clear requests for that in this same discussion) and so simply 5ms may not be enough.

If we are still talking about TimeSpan-specific literals (I am) and not the user-defined ones (I am not), I think it should be fair (at least to start with) for the literal syntax to have the same goals and limitations of the From* form.
So the question is: how is it possible to create a TimeSpan today by specifying directly x hours, y seconds, z milliseconds, ... while using the From* ? It's not, you must use the ctor directly.

I think anyone is used to say TimeSpan.FromSeconds(90) and to not pretend to say something like TimeSpan.FromMinutesAndSeconds(1, 30) or something like that: niche need? Use the ctors, so the same rules should apply for the literal counterpart.

So would the literal syntax cover all the possible ways to create it? Surely not, but it would cover (imho) the vast majority of common use cases, and for the rest we can still use the various ctors.

In a way it can be seen as top-level statements: not strictly needed (and no syntactic sugar ever is, tbh), but a way for the language to be easily usable, more approachable, more welcoming to newcomers, etc.
Even though for this, I know, we are talking about tastes, and tastes are personal, so.

These APIs are expensive to call, but if it's done at compile time that's perhaps no big deal. Using the Parse/Format APIs is actually how other language literals effectively work (including System.Decimal, which is another non-runtime primitive with literal support).

Interesting, I honestly haven't noticed that: so it has been done before, it would not be the first case.

Beyond that, it's also provided various From* APIs, like FromHours, which take in a double. These have historically been somewhat "inaccurate" due to the simple fact that double itself is a binary-based floating-point format and cannot exactly represent many decimal values. If these APIs were to be used, there would end up being discussion points on whether or not 5.5ms should work and if they did, what it would mean given that we have changed the implementation to better balance accuracy and perf and may continue to do so in the future.

Again, unless I'm missing something, same rules as the From* counterpart.

What I mean is that if today I write in my code TimeSpan.FromSeconds(5) it would work, because it will interpret 5 as a double (it's the only overload available), and the same would happen to 5s. Do a TimeSpan.FromSeconds(5.5) vs 5.5s? Same thing.

Now, let's say tomorrow a new overload will be added with a long param: upong recompile, all my existing From* call sites would switch to the new overload, right? Maybe even slightly changing the behaviour?
Again, same thing for the literal syntax.

To reiterate, my proposal is to take %NUMBER%ms and lower that into TimeSpan.FromMilliseconds(%NUMBER%), so I feel like - and maybe I'm wrong, ofc - all the same rules should apply.

A new future suffix (eg: ns for nanoseconds) arrives? Same as a new From* method.
New base numeric type accepted (eg: long on top of double)? Same as a new From* overload.

In both cases all existing call sites would either A) remain the same or B) be automatically upgraded.

Does this make sense or am I missing something?

Using these From* APIs would be "net new" and unique to TimeSpan, that makes it a newish concept for the language with newer considerations.

Fair point, on the other hand though:

• this is why this proposal exist, to see if it makes sense and is worth it (to you it's not, fair enough)
• as said TimeSpan is honestly quite unique, like the approach would be
• btw Decimal precedent
• honestly no new unit/suffix can be reasonably expected to appear out of thin air to express time (and in that case, see above)

We added support for Microseconds in relatively recent releases as well.
[...]
In .NET 9 we are now exposing additional overloads that take in long rather than double. This allows them to be exact and even more performant in many cases. But, it would lock any such language support to precisely .NET 9+ and it wouldn't work downlevel

Would this be the first time a language feature is supported only from a certain .NET version? Honest question, I don't remember right now and it's quite late here.
Anyway 5ms would be interpreted as TimeSpan.FromMilliseconds(long) when targeting .NET 9+, and as TimeSpan.FromMilliseconds(double) when targeting up to .NET 8, just like it would be for TimeSpan.FromMilliseconds(5) I suppose: changing the tfm would change the type/overload used.

Beyond all this, there are other complexities involved that also haven't been considered. This includes things like...

• How do constants work?

Same as now: no TimeSpan constants.

• How do optional parameters work?

Same as now: no TimeSpan compile-time value.

• How does constant folding of these literals work?

Same as now: no TimeSpan constant fodling.

Again, this proposal is not trying to achieve uber generic user-defined literals, nor it is trying to solve all the current limitations with struct constants: it is suggesting a syntactic sugar, like they already exist, to be then lowered to normal C# code.

Having said that, I can see a reasoning like "the fact that there's literal support would create the expectation to support these features too": if this is what you meant... fair point. But the next question is: if it has been possible with Decimal, would it be possible for TimeSpan too? Again, the next question would be "why make it special?" and the asnwer to that is in the list of unique characteristics of this type (again, imho).

The ask is seemingly simple, but in reality its actually massively complex and includes a huge amount of work in figuring out how to integrate it into the language (past, present, and future) and even what it means for the underlying BCL implementation and what type of changes/improvements we can safely make in the future.

It didn't seem simple for the outside, I can tell you that 😅, I'm just using this place to explore this idea.

Different creation APIs may do more or less things and may sometimes produce different results, depending. It all depends on the how the language would decide to bind/implement the feature.

As said, direct lowering: 5ms -> TimeSpan.FromMilliseconds(5), with all the the base types (double vs long) reasoning highlighted above.

The consideration is that once the language starts binding against TimeSpan APIs and making them intrinsically known, the behavior of them is essentially "locked in", which means that changes to the underlying implementation can be subtly breaking to the language.

Fair point, but it seems to happen today, too (see double to long automatic switch upon recompile).
But honestly I can see the doubts in deciding to create such a "strong link".

It's not as simple as "some users want TimeSpan literals, so lets expose TimeSpan literals"

Fair, totally. Even though I think TimeSpan is quite special for the reaons outlined (meaningg, not because of a personal need).

what about users who want Guid literals

I know it's just an example, but since you mentioned it:

• different Guid formats to support (with/without separators, etc)
• nobody writes Guids manually, let's be real
• the saving would be ridiculous (just the start/end " I suppose)

or who want Int128 literals, what about TimeOnly literals or DateTime literals, what about Half literals for Machine Learning, what about ....

Fair, even though for DateTime I explained the reasoning in the very proposal (multiple types, extra and subtle complexities, etc), for TimeOnly is kinda the same theme, while for Int128 and Half... I don't know enough about their usage, so I trust you in that it may be the same.

Ok, long wall of text done here 😅

Whatever it will be of this, thanks again for your time, I really aprpeciate the effort to explain the intricacies behind a feature like this, and the complexities in making such a decision.

[paralaxsd]

C# arguably continues evolving towards a form that favors more compact representations of logic. New literal suffixes could be a way to move this theme forward even further. However, rather than adding suffixes for TimeSpan only, I feel there would be even more value to this idea if it realized a more generic, extendable approach.

To borrow from other languages: C++ 11 added support for user defined literals via operator overloading. Any suffix is then represented via user code that transforms a literal of some type into another type when the suffix in question is given, e.g. to represent the concept of seconds.

I think this could also be an interesting approach for C#. However, due to differences to C++ the feature would have to be designed in a way so developers can resolve suffix clashes when a specific literal type is bound to the same suffix name multiple times.

[jodydonetti]

I thought about user-defined literals, but see here for my thoughts on this #7982 (reply in thread)

[paralaxsd]

Thanks, that all makes sense to me.
I mostly wanted to bring up the C++ operator example to add to the space of ideas.
Real world budgetary and time constraints may indeed favor a more incremental design.

[noraa-junker]

Why is us microseconds? μ looks like an u, but it definitely isn't. It is an m. I think this could cause some confusion. I suggest using micros instead.

[raffaeler]

While there is no suggestion in the SI papers, the u letter has always been used in all the scientific and technical software I know.
For example, Matlab accepts both u and micro for $10^{-6}$ but of course the shorter u is usually the most popular choice in real-life code.
BTW m is obviously milli ($10^{-3}$).

[jodydonetti]

Exactly, it is the norm to use u to mean "micro", even if it is pronunced "mu".

[noraa-junker]

I see. When it is a norm, I guess it is ok.

[wesnerm]

Isn't us already used for unsigned short?

[jodydonetti]

I don't think so, the only 2 letter suffixes starting with u are ul/uL (see here).

[TahirAhmadov]

#6705
#5076

Related:
#1969

[jodydonetti]

User-defined literals seems really good, but I can see them having a lot of problems to solve, like multiple definitions and collisions, etc. The same can be said for ext methods, true, but here it feels like it can be even harder than that.

I'm all for it, theoretically, but I can see we will still be here discussing it in 2 years and never have them landed.

So my position is to try to pick a syntax that:

1. would be extensible in the future to allow for user-defined literals, without doing it right now (even a different syntax than the one proposed, ofc)
2. make the TimeSpan literal syntax now, as a first working example on a type that is ubiquitous and rock solid, to allow us to get the benefits early, while allowing it to become "one of" the extensions in the future, if that future will ever arrive

Does it make sense?

[matejskubic]

Why not to use well known specifications from the ISO8601 (also used in XML world) with prefix P for periods and PT for time periods. Everything after T is time (part of a day).

Examples:

• 120 seconds: PT120S
• 10 minutes: PT10M
• 1 month: P1M

References:

• https://en.wikipedia.org/wiki/ISO_8601#Durations
• https://www.w3.org/TR/xmlschema-2/#duration

[jodydonetti]

Good question!

Because of the reasons I highlighted here https://twitter.com/jodydonetti/status/1764575116468355493

No wait, I don't mean that this specific char sequence may generate a collision (which as you said would be realistically rare), but that any char seq starting with a letter is a valid variable name.

You may think "that was true even when they introduced the new async keyword", but the difference here is that "PTetc" would not be a single new identifier, but an identifier pattern, meaning "any identifier starting with PT would be absorbed", which is probably too "devastating", imho.

ps: the only existing working prefix is "0b" for binary values, which starts with a number and not a letter (and it has been there since the beginning).

[andreadottor]

Not only that, there are also these:
0f -> float
0d -> double
0m -> decimal (money)
0u -> unsigned int
0l ->long
0ul -> unsigned long

[jodydonetti]

Nope, these are suffixes, 0b is a prefix, see here.

ps: I made a typo above, since 0x is for hex while 0b is for binary (I already corrected for future readers).

[iam3yal]

I'm not opposed to idea but this seems to be such a can of worms without user define literals so I imagine the syntax needs to be something that wouldn't block their ability to evolve the language, allow the BCL to take advantage over this and still allows users to customize the behaviour to their specific cases.

1. Say the LDT adds the following syntax <Expr>`<UserDefinedLiteral>.
2. Then BCL team adds various literals support to TimeSpan so you can for example write 10`s.
3. But then they decided not to support nanoseconds and leave it to 3rd party dev.

I missed @HaloFour's comment above I agree that the upcoming extension feature should cover this for the most part where you could do something like 10.s it might not be the most attractive syntax but it does solve the problem.

[jodydonetti]

I thought about user-defined literals, but see here for my thoughts on this #7982 (reply in thread)

[iam3yal]

@jodydonetti I understand your POV but in practice I don't think it's any different than extensions and there should be a balance and tradeoffs between having specific and general features in the languages and imo it's one of the cases that you need to think how the ecosystem as a whole can benefit from it to be worth it so I'd prefer them to introduce user defined literals to support specific types as opposed to a specific syntax that only targets TimeSpan.

[iam3yal]

On top of this, creating such wide ext methods on core types like int has always been discouraged by the .NET team, if I remember correctly.

To every rule there is an exception and if you organize your extensions well like MyProject.SomeNameSpace.TimeSpanExtensions then you can decide whether you actually want these extensions so they wouldn't be available every time you type an integer or whatever, I can't remember whether you still need to do it with the new extensions feature or how it works.

[jodydonetti]

To every rule there is an exception and if you organize your extensions well like MyProject.SomeNameSpace.TimeSpanExtensions then you can decide whether you actually want these extensions so they wouldn't be available every time you type an integer or whatever,

Again, these problems would remain:

The main problem with this approach is that working with TimeSpan is so ubiquitous that having to do either of those things in each and every project seems really overkill.
[...]
Also, such approaches do not allow for a wider usage (see parsing/formatting above), and would not be usable in tutorials, samples, blog posts, etc and that would reduce the advantages of a native approach.

It would not be a cohesive solution widely applicable, but a local "hack" done project-by-project.

I can't remember whether you still need to do it with the new extensions feature or how it works.

Eh, we'll see if and when "extensions everything" will finally arrive, maybe, one day.

[iam3yal]

@jodydonetti

Again, these problems would remain:

You're right about some of these issues but this is the nature of things and it's not unique to TimeSpan or even to the .NET ecosystem and even though it's a common type it seems the LDT isn't so intrigue with the idea so you have to accept it and use whatever feature that exists to come close.

A personal example is I use DbC quite a bit in my projects and I have a contract library that whenever I need it I have a project template that bundles with it and I'm happy about it, now, do I want this feature to exist in the language? YES, but I can just hope.

It would not be a cohesive solution widely applicable, but a local "hack" done project-by-project.

Just because the language lack a feature doesn't mean it's a "hack" or even a workaround... I mean it's actually the norm to use packages regardless to how common a type is.

Eh, we'll see if and when "extensions everything" will finally arrive, maybe, one day.

This is literally happening.

[Mrxx99]

Would be great if this also would allow it to be used as default parameters like this:

public void M(TimeSpan t = 100ms)
{
}

[nczsl]

I think it should be like this. Following the existing approach, we now have two ways to format numbers: binary and hexadecimal. By extending this approach, we don't need to invent anything new, which adds more mental burden to the already rich and even cluttered features of C #; The following is the existing number format, 1:0b010101:010101; 2: 0x3a8f07; On this basis, it is entirely possible to develop a solution for TimeSpan. Of course, according to me, all numerical suffixes should also be included, as this is not convenient in itself. Only int is the default, and there are options for suffixes such as f/d/l, short/byte/half/decimal? Some seem to be missing, which brings great trouble and inconvenience to use. It is recommended to add optional suffixes to all numbers as soon as possible