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
