Bug in D!!!

Sun Sep 3 18:50:48 PDT 2017

On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta 
wrote:
> On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner 
> wrote:
>> On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta 
>> wrote:
>>> On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner 
>>> wrote:
>>>> On Saturday, 2 September 2017 at 23:12:35 UTC, 
>>>> EntangledQuanta wrote:
>>>>> [...]
>>>>
>>>> The contexts being independent of each other doesn't change 
>>>> that we would still be overloading the same keyword with 
>>>> three vastly different meanings. Two is already bad enough 
>>>> imho (and if I had a good idea with what to replace the "in" 
>>>> for AA's I'd propose removing that meaning).
>>>
>>> Why? Don't you realize that the contexts matters and [...]
>>
>> Because instead of seeing the keyword and knowing its one 
>> meaning you also have to consider the context it appears in. 
>> That is intrinsically more work (though the difference may be 
>> very small) and thus harder.
>>
>> ...
>
> Yes, In an absolute sense, it will take more time to have to 
> parse the context. But that sounds like a case of 
> "pre-optimization".

I don't agree, because once something is in the language syntax, 
removing it is a long deprecation process (years), so these 
things have to be considered well beforehand.

> If we are worried about saving time then what about the 
> tooling? compiler speed? IDE startup time? etc?
> All these take time too and optimizing one single aspect, as 
> you know, won't necessarily save much time.

Their speed generally does not affect the time one has to spend 
to understand a piece of code.

>
> Maybe the language itself should be designed so there are no 
> ambiguities at all? A single simple for each function? A new 
> keyboard design should be implemented(ultimately a direct brain 
> to editor interface for the fastest time, excluding the time 
> for development and learning)?

I assume you mean "without context sensitive meanings" instead of 
"no ambiguities", because the latter should be the case as a 
matter of course (and mostly is, with few exceptions such as the 
dangling else ambiguity in C and friends).
Assuming the former: As I stated earlier, it needs to be worth 
the cost.

>
> So, in this case I have to go with the practical of saying that 
> it may be theoretically slower, but it is such an insignificant 
> cost that it is an over optimization. I think you would agree, 
> at least in this case.

Which is why I stated I'm opposing overloading `in` here as a 
matter of principle, because even small costs sum up in the long 
run if we get into the habit of just overloading.

> Again, the exact syntax is not import to me. If you really 
> think it matters that much to you and it does(you are not 
> tricking yourself), then use a different keyword.

My proposal remains to not use a keyword and just upgrade 
existing template specialization.

>
> When I see something I try to see it at once rather [...]

>
> To really counter your argument: What about parenthesis? They 
> too have the same problem with in. They have perceived 
> ambiguity... but they are not ambiguity. So your argument 
> should be said about them too and you should be against them 
> also, but are you? [To be clear here: foo()() and (3+4) have 3 
> different use cases of ()'s... The first is templated 
> arguments, the second is function arguments, and the third is 
> expression grouping]

That doesn't counter my argument, it just states that parentheses 
have these costs, as well (which they do). The primary question 
would still be if they're worth that cost, which imho they are. 
Regardless of that, though, since they are already part of the 
language syntax (and are not going to be up for change), this is 
not something we could do something about, even if we agreed they 
weren't worth the cost.
New syntax, however, is up for that kind of discussion, because 
once it's in it's essentially set in stone (not quite, but *very* 
slow to remove/change because of backwards compatibility).

>>>>> [...]
>>>>
>>>> Well, yes, as I wrote, I think it is unambiguous (and can 
>>>> thus be used), I just think it shouldn't be used.
>>>
>>> Yes, but you have only given the reason that it shouldn't be 
>>> used because you believe that one shouldn't overload keywords 
>>> because it makes it harder to parse the meaning. My rebuttal, 
>>> as I have said, is that it is not harder, so your argument is 
>>> not valid. All you could do is claim that it is hard and we 
>>> would have to find out who is more right.
>>
>> As I countered that in the above, I don't think your rebuttal 
>> is valid.
>
> Well, hopefully I countered that in my rebuttal of your 
> rebuttal of my rebuttal ;)

Not as far as I see it, though I'm willing to agree to disagree :)

>>> I have a logical argument against your absolute restriction 
>>> though... in that it causes one to have to use more symbols. 
>>> I would imagine you are against stuff like using "in1", 
>>> "in2", etc because they visibly are to close to each other.
>>
>> It's not an absolute restriction, it's an absolute position 
>> from which I argue against including such overloading on 
>> principle.
>> If it can be overcome by demonstrating that it can't sensibly 
>> be done without more overloading and that it adds enough value 
>> to be worth the increases overloading, I'd be fine with 
>> inclusion.
>
> [...]
>
> To simplify it down: Do you have the sample problems with all 
> the ambiguities that already exist in almost all programming 
> languages that everyone is ok with on a practical level on a 
> daily basis?

Again, you seem to mix ambiguity and context sensitivity.
W.r.t. the latter: I have a problem with  those occurences where 
I don't think the costs I associate with it are outweighed by its 
benefits (e.g. with the `in` keyword overloaded meaning for AA's).

>>
>>>
>>>
>>>>> [...]
>>>>
>>>> Why do you think that? Less than ten people have 
>>>> participated in this thread so far.
>>>
>>> I am not talking about just this thread, I am talking about 
>>> in all threads and all things in which humans attempt to 
>>> determine the use of something. [...]
>>
>> Fair enough, though personally I'd need to see empirical proof 
>> of those general claims about human behaviour before I could 
>> share that position.
>
> Lol, you should have plenty of proof. Just look around. [...]

Anectodes/generalizing from personal experiences do not equate 
proof (which is why they're usually accompanied by things like 
"in my experience").

>
> I'd like to see such a feature implemented in D one day, but I 
> doubt it will for whatever reasons. Luckily D is powerful 
> enough to still get at a solid solution.. unlike some 
> languages, and I think that is what most of us here realize 
> about D and why we even bother with it.

Well, so far the (singular) reason is that nobody that wants it 
in the language has invested the time to write a DIP :p