Pattern matching is-expressions
uplink.coder at googlemail.com
Wed Aug 19 15:18:03 UTC 2020
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
>> 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
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
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
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
More information about the Digitalmars-d