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.