Bug in D!!!

[Moritz Maxeiner via Digitalmars-d-learn]

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.

>
> Again, I'm not necessarily arguing for them, just saying that 
> one shouldn't avoid them just to avoid them.
>
>
>>
>>> [...]
>>
>> It's not about ambiguity for me, it's about readability. The 
>> more significantly different meanings you overload some 
>> keyword - or symbol, for that matter - with, the harder it 
>> becomes to read.
>
> I don't think that is true. Everything is hard to read. It's 
> about experience. The more you experience something the more 
> clear it becomes. Only with true  ambiguity is something 
> impossible. I realize that in one can design a language to be 
> hard to parse due to apparent ambiguities, but am I am talking 
> about cases where they can be resolved immediately(at most a 
> few milliseconds).

Experience helps, of course, but it doesn't change that it's 
still just that little bit slower. And everytime we encourage 
such overloading encourages more, which in the end sums up.

>
> You are making general statements, and it is not that I 
> disagree, but it depends on context(everything does). In this 
> specific case, I think it is extremely clear what in means, so 
> it is effectively like using a different token. Again, everyone 
> is different though and have different experiences that help 
> them parse things more naturally. I'm sure there are things 
> that you might find easy that I would find hard. But that 
> shouldn't stop me from learning about them. It makes me 
> "smarter", to simplify the discussion.

I am, because I believe it to be generally true for "1 keyword 
|-> 1 meaning" to be easier to read than "1 keyword and 1 context 
|-> 1 meaning" as the former inherently takes less time.

>
>
>>> [...]
>>
>> 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.

>
> 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.

>
>>> [...]
>>
>> I would much rather see it as a generalization of existing 
>> template specialization syntax [1], which this is t.b.h. just 
>> a superset of (current syntax allows limiting to exactly one, 
>> you propose limiting to 'n'):
>>
>> ---
>> foo(T: char)      // Existing syntax: Limit T to the single 
>> type `char`
>> foo(T: (A, B, C)) // New syntax:      Limit T to one of A, B, 
>> or C
>> ---
>
> Yes, if this worked, I'd be fine with it. Again, I could care 
> less. `:` == `in` for me as long as `:` has the correct meaning 
> of "can be one of the following" or whatever.
>
> But AFAIK, : is not "can be one of the following"(which is "in" 
> or "element of" in the mathematical sense) but can also mean 
> "is a derived type of".

Right, ":" is indeed an overloaded symbol in D (and ironically, 
instead of with "in", I think all its meanings are valuable 
enough to be worth the cost). I don't see how that would 
interfere in this context, though, as we don't actually overload 
a new meaning (it's still "restrict this type to the thing to the 
right").

>

>
> If that is the case then go for it ;) It is not a concern of 
> mine. You tell me the syntax and I will use it. (I'd have no 
> choice, of course, but if it's short and sweet then I won't 
> have any problem).

I'm discussing this as a matter of theory, I don't have a use for 
it.

>
>>> [...]
>>
>> Quoting a certain person (you know who you are) from DConf 
>> 2017: "Write a DIP".
>> I'm quite happy to discuss this idea, but at the end of the 
>> day, as it's not an insignificant change to the language 
>> someone will to do the work and write a proposal.
>>
>
> My main issues with going through the trouble is that basically 
> I have more important things to do. If I were going to try to 
> get D to do all the changes I actually wanted, I'd be better 
> off writing my own language the way I envision it and want 
> it... but I don't have 10+ years to invest in such a beast and 
> to do it right would require my full attention, which I'm not 
> willing to give, because again, I have better things to 
> do(things I really enjoy).
>
> So, all I can do is hopefully stoke the fire enough to get 
> someone else interested in the feature and have them do the 
> work. If they don't, then they don't, that is fine. But I feel 
> like I've done something to try to right a wrong.

That could happen, though historically speaking, usually things 
have gotten included in D only when the major proponent of 
something like this does the hard work (otherwise they seem to 
just fizzle out).

>
>>> [...]
>>
>> AFAIK the difference between syntax sugar and enabling syntax 
>> in PLs usually comes down to the former allowing you to 
>> express concepts already representable by other constructs in 
>> the PL; when encountered, the syntax sugar could be lowered by 
>> the compiler to the more verbose syntax and still be both 
>> valid in the PL and recognizable as the concept (while this is 
>> vague, a prominent example would be lambdas in Java 8).
>
> Yes, but everything is "lowered" it's just how you define it.

Yes and w.r.t to my initial point, I did define it as "within the 
PL itself, preserving the concept".

>
>
>>> [...]
>>
>> 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.

>>> [...]
>>
>> Why do you assume that? I've not seen anyone here claiming 
>> template parameter specialization to one of n types (which is 
>> the idea I replied to) couldn't be done in theory, only that 
>> it can't be done right now (the only claim as to that it can't 
>> be done I noticed was w.r.t. (unspecialized) templates and 
>> virtual functions, which is correct due to D supporting 
>> separate compilation; specialized templates, however, should 
>> work in theory).
>
> Let me quote the first two responses:
>
> "It can't work this way. You can try std.variant."

That is a reply to your mixing (unspecialized) templates and 
virtual functions, not to your idea of generalizing specialized 
templates.

>
> and
>
> "It is not possible to have a function be both virtual and 
> templated. A function template generates a new function 
> definition every time that it's a called with a new set of 
> template arguments. [...]"

Same here.

>
> Now, I realize I might have no been clear about things and 
> maybe there is confusion/ambiguity in what I meant, how they 
> interpreted it, or how I interpreted their response... but 
> there is definitely no sense of "Yes, we can make this work in 
> some way..." type of mentality.
>
> e.g., "Templates and virtual functions simply don't mix."
>
> That is an absolute statement. It isn't even qualified with "in 
> D".
>
>>> [...]
>>
>> Actually, I disagree here. It only *needs* filling if enough 
>> users of the language actually care about it not being there. 
>> Otherwise, it's a *nice to have* (like generics and Go, or 
>> memory safety and C :p ).
>
> Yes, on some level you are right... but again, who's to judge? 
> [...]

Ultimately, Walter and Andrei, as AFAIK they decide what gets 
into the language.