rvalues -> ref (yup... again!)

Manu turkeyman at gmail.com
Mon Apr 2 05:42:30 UTC 2018


On 1 April 2018 at 11:55, Timon Gehr via Digitalmars-d
<digitalmars-d at 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.


More information about the Digitalmars-d mailing list