Pattern matching is-expressions

[Stefan Koch]

On Wednesday, 19 August 2020 at 13:15:37 UTC, Paul Backus wrote:
> On Wednesday, 19 August 2020 at 13:07:40 UTC, Stefan Koch wrote:
>>
>> Yes it is useful.
>> And I think I have found a way to support them within the 
>> typefunctions.
>> is(T S == super) would become
>> auto f(alias T)
>> {
>>    static literal bool r = is(T S == super);
>>    // here alias S = (r ? SuperTupleOf(T) : ErrorType) is 
>> automatically declared.
>>    // where ErrorType is the value for which `!is(ErrorType)` 
>> is true
>> }
>>
>> still the pattern matching part is going to be a pain to 
>> implement correctly.
>> Without the some limitations we have right now.
>
> Why is it that type functions need their own parallel 
> implementation of an existing language feature? Shouldn't it be 
> possible to re-use the existing implementation?

Type functions work by doing partial evaluation,
In the first, static pass they can use the regular semantic 
transform and checking pass that the rest of dmd uses.
However everything which touches the type variables, cannot be 
semantically analyzed or transformed because the types aren't 
known yet.
Furthermore if during the interpretation the types are in a known 
state, you cannot change/enrich the type information within the 
AST based on that.

Since that would change the AST which would either violate the 
rule that ctfe has to be pure, and cause all sorts of issues, or 
you would have duplicate the whole subtree (this is what 
templates, do.).

Both of these things are not an option for me.

Therefore regular implementations of features can modify the 
meaning of existing nodes or indeed introduce new nodes, cannot 
be used.
As you can  see is expressions do introduce new nodes, so the 
regular implementation of them cannot just be forwarded to.
Also the existing implementation has no notion of type variables.
Since those only exist within the dynamic environment of the 
interpreter.