On type functions

Stefan Koch uplink.coder at googlemail.com
Sun May 10 07:38:06 UTC 2020


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.


More information about the Digitalmars-d mailing list