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