New Features [was Named multi-imports]

[Jesse Phillips via Digitalmars-d]

This was hard to keep reading, but ultimately enjoyable, because 
your arguments stem from interpretations and opinions of my point 
rather than the points I was making.

It is interesting that you feel I've claimed your point is 
baseless when I made no attempt to say such. Would help if I 
confirm that you do have valid arguments?

I provided a general response to a general question. You asked 
why people would be against features, which in your response has 
changed it to why people would be against features nearly 
mathematically proven to be correct.

I'm not saying we shouldn't look at the feature suggestion and 
way the pros and cons, but when you make a statement like "Adding 
language features should be see as something good, cause without 
them, we wouldn't get anywhere." it sounds more like your stating 
"Language features provide benefits, ignore the harm they cause 
it can't out weigh the harm it does."

On Wednesday, 16 August 2017 at 22:19:31 UTC, Johnson Jones wrote:
> Cost is not a one way street. When you don't do something it is 
> doing something.  The whole problem with backwards 
> compatibility is that it
> is based on ignorance.

But it isn't, your examples are all new, unestablished products 
which have no market to keep. There is a reason C++, Java, C#, C, 
Go, and countless other products keep backwards compatibility and 
it has nothing to do with ignorance. There is evidence even 
within the D community and Python, that breaking backwards 
compatibility does enough harm that it could be argued the change 
wasn't worth it (especially if done routinely).

>> D may have a number of features which C++ doesn't and visa 
>> versa, the complexity of the language for C++ to have those 
>> features means I work with D and not C++.
>
> Then why are you so against adding features? That is what made 
> D better than C++?

I didn't say that D features made it better than C++. I did say 
that the complexity of C++ has kept me away from it.


> If you can find a specific reason why having such a notation is 
> wrong then that would be a valid point, but generalities that 
> don't apply is not helpful to the cause.

I did which you know since that is the very next thing you touch 
on.

> As far as your argument about ambiguities, that already exists, 
> so it is not a problem with a new feature that extends what we 
> have(it might inherit the problem, but it is not the cause of 
> it). So, you should talk to walter about fixing that.

But ambiguities don't exist. If I name an import the compiler 
knows exactly which symbols I'm referring to. In fact named 
imports is one of the solutions Walter put in place to fix the 
ambiguity problem which you're now wanting to introduce into one 
of the approaches to solving the problem.

> My main argument is that your two arguments: 1. Adding language 
> features is bad. 2. The proposed idea creates the issue of 
> ambiguity between identical symbols.

But I didn't make the argument that "adding language features is 
bad." I made the argument that "adding language features has a 
cost." And to be more explicit, "it has a cost and you should be 
aware of the cost making the choices based on what the pros are 
with the costs and the weight of those pros and costs."

> 2. The ambiguity is, at it's root, part of D's module system 
> design and part of D's problem, not the addition of something 
> new on top of it. It cannot be fixed by not adding the addition 
> and can't be fixed by choosing not to have it. So it too is 
> irrelevant. If, it were to complicate the addition and make the 
> addition have new problems, then that is a valid argument, but 
> that is something you have to prove or show, which you haven't 
> done.

D has facilities for handling ambiguity, it is at the root of D, 
part of D's module system design. This argument only shows you 
are not aware or understand D's approach to solving the problem.

> So what I have ended up doing, rather than really defend my 
> proposal for what it is and does, is have to correct your logic 
> so that maybe we hopefully get somewhere. Note that none of 
> this is an attack on you so don't get upset.  I simply would 
> like to see this feature get implemented if it is a good idea, 
> and if it not, then I don't want it to... but before we can 
> determine that in a correct way, we first have to judge it for 
> what it is rather than what it is not.

Right, that is why I started with the general arguments, we have 
to be using the same decision making logic. Your view of features 
suggested that your approach to decision making differs from that 
of the top D contributors and a portion of the community. My 
logic could be wrong, but reflecting back to my first paragraph, 
you aren't going to be able to correct my logic if you don't 
understand what that logic is and instead go on a rampage of a 
view some fictitious person has in your head.