Vision for the D language - stabilizing complexity?

[Andrei Alexandrescu via Digitalmars-d]

On 7/9/16 6:58 PM, Andrew Godfrey wrote:
> 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?
>
> First, I'm not proposing a change to existing keywords, I'm using
> existing examples to talk about future language changes. Second, I had
> to look up "metonymy" in Wikipedia. Using its example: Suppose
> "Hollywood" referred to both the LA movie industry and, say, the jewelry
> industry; that's roughly equivalent to the pattern I'm talking about.

Way ahead of ya. The average English noun has 7.8 meanings, and the 
average verb has 12.

> Others in this thread have suggested alternatives, many of those have
> things to criticize, but I would prefer something cryptic over something
> that has multiple subtly-different meanings in the language.
> I'm drawn to "#if", except people might end up thinking D has a macro
> preprocessor. "ifct" seems fine except I'm not sure everyone would agree
> how to pronounce it. Compile-time context seems significant enough that
> maybe it warrants punctuation, like "*if" or "$if".

No. As an aside I see your point but "static if" is the worst example to 
support it, by a mile.

> I especially want to establish: If we were adding a new feature as
> significant as "static if", and we decided a keyword was better than
> punctuation, could we stomach the cost of making a new keyword, or would
> we shoehorn it either into one of the existing keywords unused in that
> context, or start talking about using attributes? I have a lot of
> experience with backward-compatibility but I still don't understand the
> reticence to introduce new keywords (assuming a freely available
> migration tool).

It just depends. There is no rigid strategy here. Worrying about the 
hypothetical possibility seems unnecessary.


Andrei