Extension type missing features

[daniel-white]

I have a few things I think might be missing from the C# 13's new extension types

1. Control/gating mechanism. It would be nice if there was some method invoked when either implicitly or explicitly converting to an extension type. This would help with a pattern similar to discriminated unions. Operators have a chance to reject a conversion by throwing. Throwing definitely isn't preferred but a Try... might be clunky.

explicit extension Person for JsonElement
{
     static void Adopt(JsonElement el)
     {
         if (el.GetString("$type") != "person")
         {
             throw new Exception("unable to adopt");
         }
     }
}

2. Interfaces. I didn't see it demoed and I doubt extensions have a virtual dispatch. But using interfaces as a constraint to ensure that the extension type has certain members would be beneficial for consistency in a codebase.

interface INamed
{
    string Name { get; }
}

implicit extension Person : INamed for JsonElement
{
    // must implement INamed
}

implicit extension Part : INamed for JsonElement
{
    // must implement INamed
}

3. Constructors. It would be nice to be able to define a new constructor for a type. IIRC, extensions have access to their own state, so injecting that via a constructor would be beneficial. This could also be another pattern for a gating mechanism.

[colejohnson66]

As I understand it, constructors on extensions is something the team is looking at, but it will not be in C# 13. The plan is to release something and improve it later.

It's the same with readonly on primary constructors. Release something that works, get feedback, then improve.

[HaloFour]

All three are being discussed. Check out the issue here: #5497

The team is definitely interested in gating/validation of explicit extensions, and there's a whole question/conversation as to how conversions work.

Extension implementation is also a goal as it enables type classes, but it is unlikely to make it for C# 13 given the runtime ramifications.

Extension constructors have been mentioned recently too, although I've not heard anything concrete as to how they would behave.

[TahirAhmadov]

I think gating/validation for explicit extensions is very important for that feature to be useful. Absent such a mechanism, it looks a lot like a pit of failure to me.

[HaloFour]

We were chatting about that on the Dotnet Evolution Discord yesterday and it does seem like something that the team is very interested in. It's still under discussion but it sounds like:

1. Explicit extensions would get an explicit conversion operator by default, but not an implicit conversion operator.
2. That explicit conversion operator can be instead provided by the developer, which would allow for validation that can throw if the conversion were to fail.
3. An implicit conversion operator can also be provided if the developer chooses.
4. There is interest in a custom is operator for pattern matching that can inspect the underlying type, so given (syntax is 100% spaghetti I invented):

   public explicit extension PersonNode for JsonObject {
       public static bool operator is(JsonObject x) {
           return x.GetString("$type") == "person";
       }
   }
   
   JsonObject json = ...;
   switch (json) {
       case PersonNode node:
           ...
   }

[Mrxx99]

The "is operator" is what would make explicit extensions useful for me.

[KennethHoff]

With explicit extensions being kind of ( but not really) functional/TypeScript-like", it would be nice if something akin to the following TypeScript code was possible.

type JsonString = string & { _type: "json }; // branded type - this would be the explicit extension.


function isJson(value: string): value is JsonString {
    // Logic to determine whether it's a Json string, returning true if it is, and false if it isn't.
}


const str = ....; // type: string

if(isJson(str)) {
   // str is now type: JsonString
}

[TahirAhmadov]

Both involve validation and converting

There is no "converting", though. That's the part I don't seem to be able to get across to you. The only thing we have with extensions is validation.
Validation and converting != validation only.

[HaloFour]

There is no "converting", though.

I don't see why there needs to be a distinction, certainly not one that necessitates designing two features that do the same thing. I see performing an is pattern and coming out the other end with another type, whether that be an extension or a different runtime type. The fact that it is actually the same type and the extension is elided is, again, an implementation detail.

[CyrusNajmabadi]

I don't understand the ambiguity. What's ambiguous in the above?

[TahirAhmadov]

I don't see why there needs to be a distinction,

There doesn't need to be a distinction - there is a distinction. I'm not the one who doesn't want there to be logic to do conversion - by design, there can be no conversion logic.

I see performing an is pattern and coming out the other end with another type

At the call site, sure - I'm not against using the is operator for both concepts. It's on the implementation side where there clearly is a difference, and said difference has to be recognized, not massaged into an incompatible signature.

[HaloFour]

There doesn't need to be a distinction - there is a distinction.

I feel like this is something that you want to attribute here that is not necessary. The fact that there isn't an actual transformation of the data doesn't seem necessary, anymore so that such an operator would apply to something that behaves as a wrapper struct.