On Thursday, 7 May 2020 at 13:43:36 UTC, Adam D. Ruppe wrote:
> On Thursday, 7 May 2020 at 13:26:36 UTC, Stefan Koch wrote:
>> Here is how a simple FullyQualifiedName would look when written as type function:
>
> Your implementation won't pass the unit tests... the major complication of Phobos' fullyQualifiedName is reconstructing template arguments which does a *lot* more than __traits(identifier).

true! But it's a step in the right direction.

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.

On Thursday, 7 May 2020 at 17:47:11 UTC, Timon Gehr wrote:
>
> If you implement your compiler properly it is easier to not have arbitrary restrictions than it is to have them.

I work with the DMD as basis.
The less I have to touch the parser, the better.

On 07.05.20 19:51, Stefan Koch wrote:
> On Thursday, 7 May 2020 at 17:47:11 UTC, Timon Gehr wrote:
>>
>> If you implement your compiler properly it is easier to not have arbitrary restrictions than it is to have them.
> 
> I work with the DMD as basis.
> The less I have to touch the parser, the better.

Apparently the newsgroup dropped my answer to this post, so I'll try again:

It's clear that you work with DMD as the basis, but my question was simply _what_ the design mistake is that causes this sort of murky incompatibility of features. I don't see how the parser has anything to do with it, as UFCS/overloads are (hopefully) resolved in semantic.

On Friday, 8 May 2020 at 02:43:09 UTC, Timon Gehr wrote:
> On 07.05.20 19:51, Stefan Koch wrote:
>> On Thursday, 7 May 2020 at 17:47:11 UTC, Timon Gehr wrote:
>>>
>>> If you implement your compiler properly it is easier to not have arbitrary restrictions than it is to have them.
>> 
>> I work with the DMD as basis.
>> The less I have to touch the parser, the better.
>
> Apparently the newsgroup dropped my answer to this post, so I'll try again:
>
> It's clear that you work with DMD as the basis, but my question was simply _what_ the design mistake is that causes this sort of murky incompatibility of features. I don't see how the parser has anything to do with it, as UFCS/overloads are (hopefully) resolved in semantic.

The process of "calling" a type function is different from a regular function call since the arguments have to go through a conversion step before they can be given to the type function. That's probably fixable but I don't know how much time this will take.
Currently I am implementing a "quick" Proof of Concept to show the merits of this approach. Therefore I am not thinking too hard about overloading or similar matters which are tangential to showing the essential benefit of a dedicated construct for type based decisions and computation.