Showing TypeFunction style

[Stefan Koch]

On Saturday, 3 October 2020 at 10:05:23 UTC, Basile B. wrote:
> On Saturday, 3 October 2020 at 08:44:53 UTC, Stefan Koch wrote:
>> On Saturday, 3 October 2020 at 07:36:17 UTC, Jacob Carlborg 
>> wrote:
>>> On 2020-10-03 00:24, Stefan Koch wrote:
>>>
>>>> // temporarly needed because parser issues ....
>>>> auto makeAliasArray(alias[] types ...)
>>>> {
>>>>      return types;
>>>> }
>>>
>>> Not sure if other cares, but your examples will look more 
>>> appealing if you fix the parser.
>>
>> Yeah ... I know. It's one of these things I keep putting off.
>>
>> You could remove all the aliases from my example if I did fix 
>> the parser.
>
> a DIP for TypeFunction requires the parser change. There are 
> two possibilities
>
> 1. a new keyword
> 2. use a symbol, e.g like template instanciation with a bang
>
> The first soltion is absolutly aweful. It leads to deprecate an 
> identifier, which will delay the feature.
>
> The second is more likely what should be adopted. At first 
> glance I'd propose a double bang.
>
>     string templateStuff = instance!stuff();
>     string typefuncstuff = callAtCompileTime!!stuff()
>
> so after the double bang, the parser can parse a 
> TypeFuntionCallExpr call instead of a CallExpr.

Actually, no.
You can just have a rule which goes like this.
Function calls may accept types.
It doesn't change much, since just builtin types are rejected by 
the parser.
Anything else is an unresolved Identifier as far as the parser is 
concerned.