What type functions mean on a language level

[sighoya]

On Tuesday, 12 January 2021 at 20:41:02 UTC, Q. Schroll wrote:
> On Wednesday, 6 January 2021 at 13:52:39 UTC, sighoya wrote:
>> If we allow a __type__ in type position, indirectly or 
>> directly, we're able to implement generics known from other 
>> languages, e.g.:
>>
>> ```
>> method(__type__ type)(type value){...}
>> ```
>> vs
>>
>> ```
>> method(T)(T value){...}
>> ```
>
> If I replace `__type__ type` by `int i`, it is still a 
> compile-time argument.

No, it would applicate to:

```
method!(int) ==> demangledMethodInt(int value) {...}
```

Just as for the second case, however, the internals are different.

>That doesn't change the semantics, or does it?

I shouldn't except that I think the former part have to be 
eagerly checked, so you have naturally generics in D.

My point was not to introduce this scenario because we have now 
two ways to do the same thing.

Rather, I'm advocating the use of type functions to map types to 
types only s.t. the ugly parts of D through AliasSeq become 
obsolete.

Type constructors should be served only by templates, we can 
improve them to behave more like generics for example by 
providing better error messages or inferred where constraints.