On 07.10.2017 09:24, Walter Bright wrote:
> 
> I've got a lot of scar tissue from "compiler implementation difficulty is not a consideration." I don't believe that is a necessary path to a high quality language. Compiler complexity is a huge red flag that something is wrong with the design of the language.
> 
> The compiler implementation should be a joy to read and someone should be able to read the spec, read the implementation of the spec, and go yeah, of course, this is obviously correct, it's so simple!

I fully agree, my point was more that details of a specific implementation should not influence the language design (too much).

What should matter more is compiler implementation difficulty "from scratch", assuming all features that need to be supported are known from the beginning. We don't really need technical debt in the language specification.

On 2017-10-07 09:24, Walter Bright wrote:

> Even for something that's not C++'s fault, the C preprocesser, I scrapped and completely rewrote it 4 times, I believe. I think I finally got it right with Warp :-)

You mean you got it right with D ;)

-- 
/Jacob Carlborg

On 06.10.2017 03:01, Walter Bright wrote:
> On 10/5/2017 4:26 AM, Timon Gehr wrote:
>>> I know that some of the UFCS code was written without regard to hijacking.
>>> ...
>>
>> I think it is by design. Lookup first tries to find members of the type, and only if they don't exist applies UFCS lookup. Therefore, if members are added to the type or made visible, this may hijack existing UFCS usages.
> 
> It may have been done that way to avoid breaking existing code.
> 

I think so. It can break new code though. ;)

>> The way to fix it is to do UFCS lookup always and then error out if both UFCS and member lookup match, but there is probably quite some code relying on the fact that you can provide a custom implementation of a general UFCS function by just adding a member. Also, with the hijacking error if you actually meant the member function the only way out I see is to use __traits(getMember, ...) for disambiguation.
>>
>> (BTW: Local imports allow hijacking too. Maybe this one could be fixed?)
> 
> I thought that was taken care of when the whole import lookup mechanism was redone a year or two ago.
> ...

https://issues.dlang.org/show_bug.cgi?id=17589

I think the best fix is what I quickly outline at the end of the issue. It is originally a proposal of deadalnix:
https://issues.dlang.org/show_bug.cgi?id=10378#c9

> ...
> 
>>> D's name lookup rules were quite simple, and deliberately set up that way. Unfortunately, most people thought they were unintuitive. It turns out that simple algorithms are not intuitive, and we now have a fairly complex lookup system. Martin and I implemented it, and probably neither of us completely understands it. I find it regrettable that things have gotten to that state.
>>> ...
>>
>> It might make sense to sit down at some point and see what goals the complex rules try to achieve and then come up with simpler rules that achieve the same (or better) goals.
> 
> There wasn't a lack of discussion about the import lookup rules :-)
> ...

The only related issue of which I was aware was visibility of private symbols. (I.e. private symbols should not cause conflicts with public symbols in other modules.)

> ... >>> Doing this kind of wrapper doesn't work for operator overloading,
>>> which brings us back to ADL is for operator overloading.
>>
>> Why does it not work for operator overloading?
> 
> 3+s

typeof(s) could overload opBinaryRight, no?

On 09.10.2017 17:41, Timon Gehr wrote:
>> There wasn't a lack of discussion about the import lookup rules :-)
>> ...
> 
> The only related issue of which I was aware was visibility of private symbols. (I.e. private symbols should not cause conflicts with public symbols in other modules.)

(Besides local imports, that is.)