On 3/28/18 7:50 AM, Timon Gehr wrote:
> "The proposal could be amended to accept mutable ref's depending on the value-judgement balancing these 2 use cases. Sticking with const requires no such value judgement to be made at this time, and it's much easier to relax the spec in the future with emergence of evidence to do so."
> 
> Just get it right the first time. "const" is a serious API restriction, and it shouldn't be forced on anyone, even intermittently until they figure out that it is too restrictive (as well as viral).

A great way to move things forward here, Timon, is to write a pull request against the DIP with motivating text and examples.

On 01.04.2018 19:20, Andrei Alexandrescu wrote:
> On 3/28/18 7:50 AM, Timon Gehr wrote:
>> "The proposal could be amended to accept mutable ref's depending on the value-judgement balancing these 2 use cases. Sticking with const requires no such value judgement to be made at this time, and it's much easier to relax the spec in the future with emergence of evidence to do so."
>>
>> Just get it right the first time. "const" is a serious API restriction, and it shouldn't be forced on anyone, even intermittently until they figure out that it is too restrictive (as well as viral).
> 
> A great way to move things forward here, Timon, is to write a pull request against the DIP with motivating text and examples.

I agree, but unfortunately I have many other things on my plate right now. Add to this that there are six or seven other DIPs that I really ought to finish/write/implement/rebase. I'll try to get back to this soon. Here, I was trying to make sure that popular misconceptions do not gain more traction.

On 1 April 2018 at 11:55, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 01.04.2018 19:20, Andrei Alexandrescu wrote:
>>
>> On 3/28/18 7:50 AM, Timon Gehr wrote:
>>>
>>> "The proposal could be amended to accept mutable ref's depending on the value-judgement balancing these 2 use cases. Sticking with const requires no such value judgement to be made at this time, and it's much easier to relax the spec in the future with emergence of evidence to do so."
>>>
>>> Just get it right the first time. "const" is a serious API restriction, and it shouldn't be forced on anyone, even intermittently until they figure out that it is too restrictive (as well as viral).
>>
>>
>> A great way to move things forward here, Timon, is to write a pull request against the DIP with motivating text and examples.
>
>
> I agree, but unfortunately I have many other things on my plate right now. Add to this that there are six or seven other DIPs that I really ought to finish/write/implement/rebase. I'll try to get back to this soon. Here, I was trying to make sure that popular misconceptions do not gain more traction.

I'm convinced. There are lots of reasons it should not only apply to const.
I only originally went that way because it was more conservative,
easier to relax, and because the stated reason why you can't _already_
do this thing is allegedly because people freak out at the idea that a
function might return data into a temporary. 'const' prevents that
from being a possibility, but unlike C++, there are significant useful
cases for not restricting to const.
The most exciting for me is pipeline programming (ie, UFCS chains),
which are a major winning feature of D. They'll be more convenient
among other things.