Bug in D!!!

Sun Sep 3 20:54:47 PDT 2017

On Monday, 4 September 2017 at 03:08:50 UTC, EntangledQuanta 
wrote:
> On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner 
> wrote:
>> 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.
>
> That's true. But I don't see how it matters to much in the 
> current argument. Remember, I'm not advocating using 'in' ;) 
> [...]

It matters, because that makes it not be _early_ optimization.

>
>
>>
>>> 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.
>
> Yes, but you are picking and choosing. [...]

I'm not (in this case), as the picking is implied by discussing 
PL syntax.

>>> 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.
>>
>
> I know, You just haven't convinced me enough to change my 
> opinion that it really matters at the end of the day. It's 
> going to be hard to convince me since I really don't feel as 
> strongly as you do about it. That might seem like a 
> contradiction, but

I'm not trying to convince you of anything.

>
>>> 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.
>
> [...]
>
> You just really haven't stated that principle in any clear way 
> for me to understand what you mean until now. i.e., Stating 
> something like "... of a matter of principle" without stating 
> which principle is ambiguous. Because some principles are not 
> real. Some base their principles on fictitious things, some on 
> abstract ideals, etc. Basing something on a principle that is 
> firmly established is meaningful.

I've stated the principle several times in varied forms of 
"syntax changes need to be worth the cost".

>>>>> 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).
>
> Not mixing, I exclude real ambiguities because have no real 
> meaning. I thought I mentioned something about that way back 
> when, but who knows... Although, I'd be curious if any 
> programming languages existed who's grammar was ambiguous and 
> actually could be realized?

Sure, see the dangling else problem I mentioned. It's just that 
people basically all agree on one of the choices and all stick 
with it (despite the grammar being formally ambiguous).

>>>>
>>>>>
>>>>>
>>>>>>> [...]
>>>>>>
>>>>>> 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").
>
> There is no such thing as proof in life. [...]

There is a significant difference between generalizing from one 
person's point of view and following the scientific method in 
order to reach reproducible results (even in soft sciences).

>
>
>>>
>>> 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
>
> Yep.
>
> I guess the problem with the D community is that there are no 
> real "champions" of it.

There are for the specific points that interest them. Walter 
currently pushes escape analysis (see his DConf2017 talk about 
how DIP1000 improves the situation there by a lot), Andrei pushed 
std.experimental.allocator, which is still being improved to 
reach maturity.
We also have quite a few people who have championed DIPs in the 
last months (one I especially care about is DIP1009 btw).

> Many of the contributors here do not make money off of D in any 
> significant way and hence do it more as a hobby. So the 
> practical side of things prevent D from really accomplishing 
> great heights(at this point).

I actually disagree on the conclusion. From my experience, things 
primarily done for money (especially in the software business) 
are pretty much always done to the worst possible quality you can 
get away with.

>
> What we know for sure, if D does progress at a specific "rate", 
> it will be overtaken by other languages and eventually die out.

I don't see this happening anytime soon, as all other native 
system PLs are so far behind D in terms of readability and 
maintainability that it's not even funny anymore.
Regardless, should that unlikely scenario happen, that's okay, 
too, because in order for them to actually overtake D, they'll 
have to incorporate the things from D I like (otherwise they 
haven't actually overtaking it in terms of PL design).

> This is a fact, as it will happen(everything dies that lives, 
> another "over generalization" born in circumstantial evidence 
> but that everyone should be able to agree on...). D has to keep 
> up with the Kardashians if it want's to be cool... 
> unfortunately.

I can't speak for anyone else, but I'm not using D because I 
think D wants to be cool (I don't think it does), I use it 
because more often than not it's the best tool available and I 
believe the people who designed it actually cared about its 
quality.