New built-in type/entity — Symbol

[forgotten-aquilon]

Reasoning:

Alternative for const string variables and possible usage with Unions.

Explanation

Symbol SomeSymbol;

Symbols are created in compile time. Symbols are reference type. Declaration is initialization.

Symbol SomeSymbol;

void func(Symbol symb)
{
  if (symb is SomeSymbol)
  {
  ...
  }
}

There is the System.Symbol abstract base type (and possibly keyword "symbol)" with allowed boxing and unboxing for any declared symbol. Declared symbols work as static objects.

Symbol SymbolA;

var someSymbol = SymbolA;

Symbol identifiers can work both as variables or types depending on context.

Symbol None;

public Union Optional<T> : Union<T, None>
{
...
}

Possible Symbol usage with Unions for creating custom Union, where one of possible values doesn't express anything besides itself, i.e. declared Symbol represents only itself and nothing else, it doesn't contain any excessive information.

[HaloFour]

IMO if C# were to adopt something like this it would be better off with companion objects, types with singleton instances. Although it's such an easy pattern to adopt manually that honestly I'm not sure that there'd be a lot of utility to it. With value types it also feels a lot less necessary.

[jnm2]

The desire to declare something that can be used as both a type and a value has come up in discriminated unions. If a member of the union is a type and the type contains no state, it would be nice to be able to use the type as a value rather than creating new instances of the type which are all functionally interchangeable.

This Symbol concept is a particular solution to a general problem space. There is an active proposal of a different solution for the same problem space, Type Value Conversion. I don't see a championed issue for it; @mattwar are you championing it?

[CyrusNajmabadi]

it'll be possible to assign any object to variable of type of this Union.

You can have your own trivial sealed subclass of object then that is also dataless. Basically:

sealed class Symbol
{
}

static readonly Symbol SomeSpecificError = new();

Because in your case it's an object

If you want a specific type, just make a specific type, like above.

Well, it will technically work like Union<T, object>,

With the above, you can do Union<T, Symbol>.

and such type will not have relevant constraints

What constraints do you need?

it'll be possible to assign any object to variable of type of this Union.

If you have a sealed subclass, that's not the case. Only instances of Symbol would be assignable.

[HaloFour]

Do you want a string, because semantically you want a text, or because string is the best suited type to represent a value?

Because I want text. I wouldn't use a string if I didn't want text. I wouldn't use an error code if I didn't intend to display it somewhere.

To me a symbol relates back to a textual identifier, and really is only necessary to guarantee uniqueness and avoid collisions in various dynamic languages where members are just values in a map. I assume that's not what you're referencing here, except for the overlap with error code strings.

I do think there could be value in singleton instances, especially for cases like None (although the lack of a bottom type complicates matters). It's also a fairly trivial pattern to apply manually. You could define Symbol today and use it in your codebase.

[forgotten-aquilon]

@CyrusNajmabadi

You still misses the point. "SomeSpecificError" should be the new type. All new Symbols will be new types with "Symbol" being ancestor type. So it supposed to be Union<T, SomeSpecificError>. To achieve this you should write all this sealed classes for each new Symbol, and also they should be singletons to work properly. All this boilerplate can be completely replaced with just Symbol SomeSpecificError;.

---

@HaloFour

Because I want text. I wouldn't use a string if I didn't want text. I wouldn't use an error code if I didn't intend to display it somewhere.

Well, good for you. I worked (and still work) on projects where such things are completely internal:

SomeSpecificError = nameof(SomeSpecificError);

...

if (errorCode == SomeSpecificError)
{
  throw new SomeInternalException();
}

You could define Symbol today and use it in your codebase

Yes, you can, but as I wrote above each new Symbol are supposed to be a new distinct type, so you can define Symbol, but also you still need to define each new type.

---

I want to add that all ways to create new types in C# assume that a new type will represent some data, basically it's what OOP is all about. So I think it's a good thing to have a singular explicit way to create dataless objects: so when you encounter a Symbol in some codebase you immediately understand its semantics — unique label, identifier.

[CyrusNajmabadi]

All this boilerplate can be completely replaced with just Symbol SomeSpecificError;.

I see. I'm not sure i see enough value there. Just writing sealed class MySpecificError : Symbol; seems fine to me. But we'll consider this, and if we see enough value, move forward on it.

[forgotten-aquilon]

Okay, thank you!

[CyrusNajmabadi]

You're welcome :)

[HaloFour]

I worked (and still work) on projects where such things are completely internal.

If said projects aren't adopting better practices for that already why would they adopt this new feature? Nothing is stopping them from using singleton types for error handling instead of magic strings or numbers.

Yes, you can, but as I wrote above each new Symbol are supposed to be a new distinct type, so you can define Symbol, but also you still need to define each new type.

That doesn't feel remotely onerous. You only have to do it once per symbol and the consumption point would work the same way anyway.