On type functions

[Timon Gehr]

On 06.05.20 16:40, Stefan Koch wrote:
> On Wednesday, 6 May 2020 at 14:28:20 UTC, Timon Gehr wrote:
>> On 04.05.20 19:09, Stefan Koch wrote:
>>> On Monday, 4 May 2020 at 15:55:44 UTC, Paul Backus wrote:
>>>> On Monday, 4 May 2020 at 15:42:01 UTC, Steven Schveighoffer wrote:
>>>>> [...]
>>>> [...]
>>>>> [...]
>>>>
>>>> If I understand the proposal correctly, it should be ok handle UFCS 
>>>> the same way std.algorithm.map does, by taking the function as a 
>>>> template argument:
>>>>
>>>> auto map(alias f)(alias[] a) {
>>>>     // etc
>>>> }
>>>
>>> In my current draft type functions are not overload-able.
>>> And having UFCS work was never really something I thought about.
>>> I would like to work on a version which does not take UFCS just as a 
>>> first step.
>>
>> That's a bit concerning. Why would overloading and UFCS require a 
>> separate implementation for type functions and functions that do not 
>> operate on types?
> 
> ufcs doesn't work merely because of how it parses right now.
> I cannot really see where overloading a type function would make sense.

My question was, why is there a separate implementation in the first 
place? Type functions are just functions that take at least one 
parameter that includes an 'alias' type. There does not seem to be any 
reason why it should be harder to have it working than to not have it 
working.

> If you have a compelling example where it's useful. I may reconsider.

The compelling example was given already. Use std.algorithm with ranges 
of types. In any case, this is not how language design works. 
Independent language features are _supposed_ to be freely combined by 
programmers and if they can't be that's a failing on part of the 
language designer and the "I didn't think it was useful" defense is 
nonsense, because if you implement your compiler properly it is easier 
to not have arbitrary restrictions than it is to have them.