This question is (I've just realized) the primary concern I have about the future of D (and hence whether it's worth depending on).

I looked at the 2015H1 vision, and don't see an answer to this there.

So, an example to illustrate the question: In a recent thread, I saw code that used an "alias parameter". I haven't seen this before. Or have I? I'm not really sure, because:
* "alias" is a keyword I've seen before.
* type inference (which I like in general), means that maybe this is the "formal" way to specify whatever it means, and people usually just leave it out.

Now, I'm not asking about making a breaking language change, and I'm not exactly complaining about new language features. I'm more thinking about when someone who knows all the current features, tries to read code: How hard is the language for that human to parse? The more different meanings a keyword has (consider "static"), and ditto for attributes, the harder it is to parse.

Sorry for the novel, but now I can ask my question: What is the D leadership's vision for how the language will evolve with respect to this metric (ease of parseability by a human already well versed in the latest version of the language)?

I ask because I see lots of discussions that seem to be proposing a change that will incrementally  increase this difficulty. Over time, that would significantly change the language, possibly approaching C++'s level of difficulty, which I'll call "many bridges too far". And C++ seems to have given up fighting this (e.g. I like the idea of the C++ "uniform initialization" and "initializer list" features, but the way their syntax interacts with old-school syntax is frustrating.)

Thanks!

On 7/7/16 12:23 PM, Andrew Godfrey wrote:
> What is the D leadership's vision for how the language will evolve with
> respect to this metric (ease of parseability by a human already well
> versed in the latest version of the language)?

Alias parameters have been around for a while. Generally it's not a feasible strategy to assign (or assume as reader) a single context-independent meaning to a keyword.

We are always keeping a close watch on language complexity as we improve it. One thing we're looking increasingly into is shifting to the compiler the responsibility of ascribing qualifiers and attributes, thus reducing the need for writing them by humans. Walter has a few quite interesting recent ideas in the area, which may bear fruit soon.


Andrei

On Thursday, 7 July 2016 at 16:23:35 UTC, Andrew Godfrey wrote:
> So, an example to illustrate the question: In a recent thread, I saw code that used an "alias parameter". I haven't seen this before. Or have I? I'm not really sure, because:
> * "alias" is a keyword I've seen before.
> * type inference (which I like in general), means that maybe this is the "formal" way to specify whatever it means, and people usually just leave it out.
>

While I understand the sentiment, I don't think this example is a good one and Andrei answer only makes this more scary.

alias as in alias parameter is the exact same thing as alias in other situations: make this name refers to that other thing.

And here we are touching the problem: why do you expect alias to work in one place and do not expect it to work in other places ? The answer down bellow.

> I ask because I see lots of discussions that seem to be proposing a change that will incrementally  increase this difficulty. Over time, that would significantly change the language, possibly approaching C++'s level of difficulty, which I'll call "many bridges too far". And C++ seems to have given up fighting this (e.g. I like the idea of the C++ "uniform initialization" and "initializer list" features, but the way their syntax interacts with old-school syntax is frustrating.)
>

While this very true, it is clear that most D's complexity doesn't come from there. D's complexity come for the most part from things being completely unprincipled and lack of vision.

Let me get back to your alias example. alias does one thing: give a new name to some existing thing. For instance, after doing:

alias foo = bar;

I can use foo as an identifier and it will refer to bar.

Now as to parameters. Parameters are like declarations, but the value is provided in the form of an argument. For instance:

void foo(int a) {} // a is a parameter.
foo(3); // 3 is an argument.

In that specific instance, we conclude that within foo, it is as if we declared int a = 3 (in that specific case).

The concept of alias and the concept of parameter/argument are completely orthogonal, and therefore, there should be no expectation that anything special is going on. So, in

template Foo(alias A) {}
Foo!bar;

Things should be as if, for this specific instance, within Foo, we specified alias A = bar;

Except that it is not the case. D fucks up orthogonality everytime it has the opportunity. As a result, there is a ton of useless knowledge that has to be accumulated. For instance :

alias A = int; // Nope
template Foo(alias A) {}
Foo!int; // OK !

In general, things are so unprincipled that there is no expectation that they are anymore. For instance, you'd expect that

template Foo(T...) {}

would take a variadic number of type as arguments, while

template Foo(alias T...) {}

would take a variadic number of aliases. But no, 1 take a variadic number of aliases and 2/ is invalid. So now we've created a situation where it is now impossible to define variadic, alias and parameter/argument as 3 simple, separate things, but as a whole blob of arbitrary decisions.

This turtles down the the most simple thing:

enum E { A = 1, B = 2 }
E bazinga = A | B;
final switch (bazinga) { case A: ... case B: ... } // Enjoy !

And so on, @safe only mean safe if you do not do this and that, DIP25 is ready to add a new pack of brick to the already tanking Jenga tower. Shared doesn't work and Walter promote use of undefined behavior to work around them.

In fact, when it comes to news feature, more than the added complexity of the feature itself, it it's interaction with existing madness that worries me. Not only there is an explosion of special cases that is completely untractable, but it also cement the existing madness.

> Generally it's not a feasible strategy to assign (or assume as reader) a single context-independent meaning to a keyword.


That may be overstating it, yes. But I am looking here for a positive statement about what kind of addition is "beyond the pale". For example, in C++, "enum class" uses two existing keywords in a new way, but it is acceptable (although ugly as heck), because the resulting thing is 'like' an enum. OTOH, C++'s use of "static" is unacceptable, because it mixes very distinct ideas (file scope, linkage, and instancing in a class) and the context you have to look at to distinguish them is sometimes far away from the line you are looking at. I haven't really noticed this problem much with D, but I worry about the future, because I see a refusal to introduce new keywords, combined with an eagerness to introduce new language concepts. Surely a compelling enough new language concept, would justify needing to provide a migration tool to help codebases migrate to the new compiler?


Another example is "return" used for monads in eg Haskell - even if it only has one meaning in Haskell, it is too mixed up with a different meaning in other common languages. D's "static if" - which is a killer feature if I ignore the keyword - gives me a similar feeling (though it's much less egregious than "return" in monads). "static" is a terribly non-descriptive name because there are so many senses in which a thing could be "dynamic". What we mean in this case is "compile-time". I think!

On 07/08/2016 02:56 AM, deadalnix wrote:
> alias A = int; // Nope
> template Foo(alias A) {}
> Foo!int; // OK !

I think you've got "Nope" and "OK" mixed up there.

[...]
> And so on, @safe only mean safe if you do not do this and that,

As far as I'm aware, the dictatorship agrees that the holes in @safe are bugs that need fixing.

On Friday, 8 July 2016 at 00:56:25 UTC, deadalnix wrote:
> While this very true, it is clear that most D's complexity doesn't come from there. D's complexity come for the most part from things being completely unprincipled and lack of vision.

But that way is PRAGMATIC, don't you know about that? It's better to solve similar design issues in 5 places differently based on current need and then live with the problems caused forever after.

> Except that it is not the case. D fucks up orthogonality everytime it has the opportunity.

Well, there are some things kept orthogonal. Runtime and compiletime parameters are not mushed together for example. But the situation does not improve, relevant thread:
http://forum.dlang.org/post/nkjjc0$1oht$1@digitalmars.com

> As a result, there is a ton of useless knowledge that has to be accumulated.

Wanna use reflection? It's simple, just see template type destructuring syntax, is expression, __traits, std.traits, special builtin properties and functionlike-operators.

> For instance, you'd expect that
>
> template Foo(T...) {}
>
> would take a variadic number of type as arguments, while
>
> template Foo(alias T...) {}
>
> would take a variadic number of aliases. But no, 1 take a variadic number of aliases and 2/ is invalid. So now we've created a situation where it is now impossible to define variadic, alias and parameter/argument as 3 simple, separate things, but as a whole blob of arbitrary decisions.

Oh, but the current way saves 6 characters. And was what was needed at the time of implemeting it.

On 07/07/2016 10:25 PM, Andrew Godfrey wrote:
> D's "static if" - which is a killer feature if I ignore the keyword -
> gives me a similar feeling (though it's much less egregious than
> "return" in monads). "static" is a terribly non-descriptive name because
> there are so many senses in which a thing could be "dynamic".

You may well be literally the only person on Earth who dislikes the use of "static" in "static if". -- Andrei

On Friday, 8 July 2016 at 05:26:44 UTC, ag0aep6g wrote:
>> And so on, @safe only mean safe if you do not do this and that,
>
> As far as I'm aware, the dictatorship agrees that the holes in @safe are bugs that need fixing.

That's a completely meaningless statement, plus overall the dictatorship position is completely inconsistent.

It is meaningless because sometime, you have A and B that are both safe on their own, but doing both is unsafe. In which case A or B need to be banned, but nothing allows to know which one. This isn't a bug, this is a failure to have a principled approach to safety.

The position is inconsistent because the dictatorship refuses to compromise on mutually exclusive goals. For instance, @safe is defined as ensuring memory safety. But not against undefined behaviors (in fact Walter promote the use of UB in various situations, for instance when it comes to shared). You CANNOT have undefined behavior that are defined as being memory safe.

On 07/08/2016 02:42 PM, deadalnix wrote:
> It is meaningless because sometime, you have A and B that are both safe
> on their own, but doing both is unsafe. In which case A or B need to be
> banned, but nothing allows to know which one. This isn't a bug, this is
> a failure to have a principled approach to safety.

What would be a good example? Is there a bug report for it?

> The position is inconsistent because the dictatorship refuses to
> compromise on mutually exclusive goals. For instance, @safe is defined
> as ensuring memory safety. But not against undefined behaviors (in fact
> Walter promote the use of UB in various situations, for instance when it
> comes to shared). You CANNOT have undefined behavior that are defined as
> being memory safe.

I agree with that. What would be a good example? Where is the reference to Walter's promotion of UB in @safe code?


Andrei

On Friday, 8 July 2016 at 18:16:03 UTC, Andrei Alexandrescu wrote:
>
> You may well be literally the only person on Earth who dislikes the use of "static" in "static if". -- Andrei

You have to admit that static is used in a lot of different places in D. It doesn't always mean something like compile-time either. For instance, a static member function is not a compile time member function. However, I doubt something like this is going to change, so it doesn't really bother me.

I liked the way that the Sparrow language (from the presentation you posted a few weeks ago) did it. Instead of static if, they use if[ct].