Vision for the D language - stabilizing complexity?

[Seb via Digitalmars-d]

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