Proposal: User-defined literals

[alrz]

Allows integer, floating-point, character, and string literals to produce objects of user-defined type by defining a user-defined suffix; providing a nice syntax for defining units of measure and domain-specific literals in a DDD context.
There is a similar feature in F# (MeasureAttribute) and (surprisingly) C++, but I really feel the need for this in C# as well.

As a regular operator:

class Distance {
    ...
    public static literal operator Distance km(double p) { ... }
}

As an extension operator (#4945):

public static literal operator TimeSpan hour(this double h) { ... }

Using improved type aliases (#4884):

// helps with further extension methods
using Radian = double;

// maybe in another file
public static literal operator Radian deg(double degree) { ... }

Usage:

Math.Sin(30deg);

[dsaf]

Good luck 😄 #263.

[gafter]

This proposal requires a lexical grammar. Please provide one.

[alrz]

@gafter

Affected literals including:

literal:
: integer-literal
: real-literal
: character-literal
: string-literal

Since integer-literal and real-literal has already some suffix defined, they would be modified as follow:

integer-type-suffix:
: one of standard suffixes
: suffix_identifier

However, no changes to hexadecimal-integer-literal to avoid conflict with hexadecimal characters.

real-type-suffix:
: one of standard suffixes
: suffix_identifier

So far, identifiers shouldn't have conflict with predefined suffixes. To workaround this limitation, we could prepend a mandatory underline to suffix_identifier.

For character-literal and string-literal an optional suffix_identifier would be added.

character-literal:
: ' character ' suffix_identifier _opt

string-literal:
: regular-string-literal suffix_identifier _opt
: verbatim-string-literal suffix_identifier _opt

[dsaf]

There is a similar feature in F# (MeasureAttribute)

This was motivated by compile-time verification as far as I understand. Does your suggestion imply that feature as well #144?

[alrz]

@dsaf the feature I proposed here is just an alternative syntax for extension methods like 12.Hours() and since it returns another type you would naturally get compile-time verification but in F# you have more specific "units of measure" like float<g kg^-1> and float<ml/cm^3>. this is not the case here.

[gafter]

@alrz OK, thanks. What are the static semantics (i.e. type rules and/or specification by translation into existing constructs)? I presume these new literals do not designate what the language spec currently calls "constants"?

[alrz]

@gafter It will be more of a syntactic sugar similar to extension methods which provides a concise syntax for data that has units, and may return types other than those that are considered as a constant.

[gafter]

@alrz what is the advantage of this construct over extension methods?

[alrz]

@gafter it provides a concentrated syntax that implies this value is of a specific unit.

[gafter]

@alrz don't extension methods do the same?

[alrz]

@gafter you are convincing me that this is not a good idea. I do agree, it's not worth the effort.

[Unknown6656]

It could be perfect for complex number representation: #12699