On 07/09/2016 04:57 AM, Observer wrote:
>
> Also, Andrei, if you're listening, I've spotted another TDPL errata.
> On page 459, the Index entry for "static, obligatory joke about overuse
> of" lists page 345, but in fact the joke is in the footnote at the bottom
> of page 68.

Added to http://erdani.com/tdpl/errata. Thanks! -- Andrei

On 07/09/2016 12:32 AM, Andrew Godfrey wrote:
> On Friday, 8 July 2016 at 18:16:03 UTC, Andrei Alexandrescu wrote:
>> 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
>
> Aha! But I don't!

Great to hear you don't dislike it! :o) -- Andrei

On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote:
> On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote:
>
>> Aha! But I don't! It feels intuitive, possibly the best use of "static". But that is immaterial, what matters is the sum of all meanings of "static" in this language. The "single instance per class" meaning of "static" is just bonkers. I've had that meaning burned into my brain for a couple of decades, from C++. But I don't have to like it!
>> I could stomach it, though, if that was the only use of the keyword. (Or if the other meanings couldn't be used in the same contexts).
>
> The name is fine. It comes from 'statically bound/dispatched', that is 'resolved at compile time'.

This is a tangent from the subject of this thread, but: No, that just says how it is implemented, not what it means / intends. See "the 7 stages of naming", here: http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/

(That resource is talking about identifier naming, not keywords. But it applies anyway.)

On Friday, 8 July 2016 at 20:11:11 UTC, H. S. Teoh wrote:

> But yeah, D *has* overloaded the "static" keyword perhaps a little more than it ought to have.  But at the end of the day it's just syntax... there are far more pressing issues to worry about than syntax at the moment.
> T

Okay, so now you are illustrating the *exact* problem I am trying to point out with this thread: Without trying to undo the mistakes of the past, could we please have a link (in the vision doc) to a long-term language-design vision, so that potential adopters know what to expect in 5 years or 10 years?
If by then, D will be as unwieldy as C++ is now, then it isn't the improvement over C++ that it currently appears to be.

"More pressing issues" is what the current vision doc is about, and I'm not suggesting substantial changes to it. Except for the time it may take the leadership to write down their long term intentions and - possibly as an outcome of that - to resolve their differences.

I also think it could increase efficiency in the forums; any language proposal which violates the long term vision could be referred to that doc instead of clumsily exploring little bits of it.

On Saturday, 9 July 2016 at 14:58:55 UTC, Andrew Godfrey wrote:
> On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote:
>> On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote:
>>

> This is a tangent from the subject of this thread, but: No, that just says how it is implemented, not what it means / intends. See "the 7 stages of naming", here: http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
>
> (That resource is talking about identifier naming, not keywords. But it applies anyway.)

You have a point, but the name is still not 'just bonkers', all things considered. Metonymy is justified in many cases, and I think this is one of them. What better name would you propose?

On Saturday, 9 July 2016 at 16:38:02 UTC, Max Samukha wrote:
> On Saturday, 9 July 2016 at 14:58:55 UTC, Andrew Godfrey wrote:
>> On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote:
>>> On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote:
>>>
>
>> This is a tangent from the subject of this thread, but: No, that just says how it is implemented, not what it means / intends. See "the 7 stages of naming", here: http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
>>
>> (That resource is talking about identifier naming, not keywords. But it applies anyway.)
>
> You have a point, but the name is still not 'just bonkers', all things considered. Metonymy is justified in many cases, and I think this is one of them. What better name would you propose?


I agree that overloading keywords in different contexts in problematic. I think every newbie is surprised when he stumbled across the two different usages of enum (finite, custom lists & CT evaluation), but let's focus on the future. Something that's worrying me a bit, is that we don't have a clear naming convention for Phobos.

There is a good wiki entry that shows the problem [1].
Basically an intuitive name should follow a standard convention, s.t. you can "guess" it and the name can also tell more information, e.g. is it a lazy operation? (aka returns a range).

`split` and `splitter` are good examples, but then in other module you might find (1) adjectives: `transposed`, `indexed` (2) prepositions: byUTF, or (3) just nouns: setUnion, cartesianProduct, permutations, recurrence.

Disclaimer: This is just a friendly reminder that names are important and as they are very hard to change, great care should be put on choosing them in the future ;-)

[1] http://wiki.dlang.org/Naming_conventions

On 07/09/2016 07:09 PM, Seb wrote:
> I agree that overloading keywords in different contexts in problematic.
> I think every newbie is surprised when he stumbled across the two
> different usages of enum (finite, custom lists & CT evaluation),

`enum e = 1;` can be seen as a shorthand for `enum {e = 1}`. Makes perfect sense then. Though I wouldn't be surprised if there are actually subtle differences between the two.

On 09.07.2016 06:39, Andrew Godfrey wrote:
> On Friday, 8 July 2016 at 21:23:24 UTC, Timon Gehr wrote:
>> On 08.07.2016 04:25, Andrew Godfrey wrote:
>>>
>>> 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).
>>
>> 'return' in Haskell is perfectly fine.
>
> This (long) talk does a good job of explaining the problem with using
> the name 'return' in monads.
>
> https://www.infoq.com/presentations/functional-pros-cons#downloadPdf
> ...

The reason you linked to this (long) talk instead of a more digestible source is that the presenter manages to bring across his flawed argumentation in a way that is charismatic enough to fool a biased audience.

It's a reasonable name. 'return' creates a computation that returns the given value. This is a different corner in language design space, why should C constrain Haskell's design in any way?

> Others have said it shorter.

Thanks for providing the links to that material.

> I took this example because it crosses
> languages. Of course we can't avoid clashing with other languages, there
> are only so many keywords to use. But there's definitely a principle
> here worth considering, that is if you care about D adoption.
> ...

I was complaining about the cheap shot at Haskell. This has become way too fashionable.

> C# vs C++ have an example of a keyword clash too ("volatile" I think?)
>

That's a better example.

On 09.07.2016 02:26, Walter Bright wrote:
> On 7/8/2016 2:33 PM, Timon Gehr wrote:
>> On 08.07.2016 21:26, Andrei Alexandrescu wrote:
>>> Where is the reference to Walter's promotion of UB in @safe code?
>>
>> Only found this, but IIRC, there was another discussion:
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/C_compiler_vs_D_compiler_272670.html#N272689
>>
>
>
> I don't agree with the notion that all UB's can lead to memory
> corruption. deadalix's hypothetical fails because "proving it always
> passes" cannot be done at the same time as "remove this code path
> because it is undefined".
> ...

It's not the same branch. The code path that is removed ensures that the other branch always passes. Anyway, deadalnix was just illustrating how a compiler might introduce memory corruption in practice. The specification should not /allow/ the compiler to do so in the first place. @safe is checked in the front end and UB is exploited by the back end. The front end needs to be independent of the back end. Using the standard definitions of terms, any UB that makes it into the back end is allowed to introduce memory corruption -- the front end cannot know, so how can it verify it does not happen?

> I don't agree with the interpretation of UB in C++ that some C++
> compiler authors do ...

Undefined behaviour means the language semantics don't define a successor state for a computation that has not terminated. Do you agree with that definition? If not, what /is/ UB in D, and why is it called UB?

On 10.07.2016 00:36, Timon Gehr wrote:
> the language semantics don't

*doesn't