Revised RFC on range design for D2

[Andrei Alexandrescu]

Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> Because language design is putting many desiderata in agreement, not 
>> following one blindly.
>>
> 
> I don't get it. What other desiderata are in conflict? Those of other 
> people, or other desiderata of your own? Because when you say "I'd like 
> that too", I read that as meaning that, at least for your own, you would 
> prefer if such change was implemented. (ie, weighting all your concerns, 
> you still prefer the change)

It's really simple in fact. For example one desideratum is to not 
complicate the language unnecessarily. When I said I'd like that, I put 
aside the obvious cost of burdening the language. (Sorry for being unclear.)

>>>>> Requiring parentheses for some function calls, but not for others 
>>>>> violates the principle of consistency.
>>>>
>>>> No. It violates economy of syntax. There are many syntaxes for the same
>>>> semantics. 
>>>
>>> It violates consistency, as defined above.
>>
>> No. You can't define a term to mean whatever you want. I mean you can, 
>> but then it's hard to communicate.
>>
> 
> By "some functions" I meant n-args functions, and by "others" I meant 
> zero-args functions. That gives: "[Putting] parenthesis for n-args 
> function calls, but not for zero-args function calls violates the 
> principle of consistency."
> So we go back to the first point in this post.
> 
>>> It may violate economy of syntax as well (or it may be the same 
>>> thing). Whatever. What I ask is, what would you suggest to fix it? 
>>> Should all function calling not use parenthesis? And how would that 
>>> syntax be?
>>
>> I'm happy with how things are now except for the assignment that is 
>> accepted all to often. I suggested a simple fix for that.
>>
>>
>> Andrei
> 
> I don't understand that. You stated "It violates economy of syntax.", so 
>  it violates your Principle 1 of language design. So how can you be 
> happy with that (apart from the assignment issue)? Does fixing this 
> problem violate some other principle or concern of yours?

I think keeping the language simple is also a good goal.

Andrei