December 24, 2012
Put another way: how long will we probably still wait for a solution? Yet another release, or 2? Say, 6 months or even longer? When it comes in the near future (ie a maximum of 1-2 months), then it would be sufficient simply to templatize my methods. But if it goes for much longer (which I strongly go out) then I probably write both functions by myself.
December 24, 2012
One more thing: Which pull request is for "auto ref" for none-template functions?
December 24, 2012
On Monday, December 24, 2012 14:01:10 Namespace wrote:
> One more thing: Which pull request is for "auto ref" for none-template functions?

There isn't one.

- Jonathan M Davis
December 24, 2012
On Monday, December 24, 2012 12:16:15 Namespace wrote:
> Put another way: how long will we probably still wait for a solution? Yet another release, or 2? Say, 6 months or even longer? When it comes in the near future (ie a maximum of 1-2 months), then it would be sufficient simply to templatize my methods. But if it goes for much longer (which I strongly go out) then I probably write both functions by myself.

I have no idea. It's a known issue, and we want it solved, but there is no ETA for when it will be solved. It could be soon or it could be quite a while.

- Jonathan M Davis
December 24, 2012
On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis wrote:
> On Monday, December 24, 2012 00:48:01 Namespace wrote:
>but Andrei is dead set against
> - Jonathan M Davis

Why?

December 24, 2012
On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
> On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
> 
> wrote:
> > On Monday, December 24, 2012 00:48:01 Namespace wrote:
> >but Andrei is dead set against
> >
> > - Jonathan M Davis
> 
> Why?

He's convinced that it's caused problems for C++ and was a major mistake. You can search the newsgroup for discussions on it. The most recent one which involved Andrei was in the beta group:

http://forum.dlang.org/post/4F84D6DD.5090405@digitalmars.com

- Jonathan M Davis
December 24, 2012
On 12/24/12 12:11 PM, Jonathan M Davis wrote:
> On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
>> On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
>>
>> wrote:
>>> On Monday, December 24, 2012 00:48:01 Namespace wrote:
>>> but Andrei is dead set against
>>>
>>> - Jonathan M Davis
>>
>> Why?
>
> He's convinced that it's caused problems for C++ and was a major mistake. You
> can search the newsgroup for discussions on it. The most recent one which
> involved Andrei was in the beta group:
>
> http://forum.dlang.org/post/4F84D6DD.5090405@digitalmars.com
>
> - Jonathan M Davis

An important smoking gun is C++'s min(), which is allows writing unsafe code without casts.

const int& haveANiceDay = min(4, 5);


Andrei
December 24, 2012
On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
> An important smoking gun is C++'s min(), which is allows writing unsafe
> code without casts.
> 
> const int& haveANiceDay = min(4, 5);

But what does that have to do with const& for function parameters? I can agree that it's bad for local variables like that, but such references aren't legal in D anyway - const or not. const& on function paramters merely avoids a copy, and as long as you don't take the reference of that parameter (which you can't do in D) and then assign it to something or return it, it can't survive past the point that it leaves scope.

I get the impression that your complaints about rvalue references stem from issues with them that have nothing to do with function parameters, and it's the function parameters that everyone cares about.

That being said, I don't think that having const ref take rvalues is a good solution for D given how strict its const is - rather I think that we should figure out how to make auto ref work for non-templated functions - but I fail to see how making const ref accept rvalues would really cause any problems.

- Jonathan M Davis
December 24, 2012
On Monday, 24 December 2012 at 17:37:54 UTC, Andrei Alexandrescu wrote:
> On 12/24/12 12:11 PM, Jonathan M Davis wrote:
>> On Monday, December 24, 2012 17:55:23 Minas Mina wrote:
>>> On Sunday, 23 December 2012 at 23:59:55 UTC, Jonathan M Davis
>>>
>>> wrote:
>>>> On Monday, December 24, 2012 00:48:01 Namespace wrote:
>>>> but Andrei is dead set against
>>>>
>>>> - Jonathan M Davis
>>>
>>> Why?
>>
>> He's convinced that it's caused problems for C++ and was a major mistake. You
>> can search the newsgroup for discussions on it. The most recent one which
>> involved Andrei was in the beta group:
>>
>> http://forum.dlang.org/post/4F84D6DD.5090405@digitalmars.com
>>
>> - Jonathan M Davis
>
> An important smoking gun is C++'s min(), which is allows writing unsafe code without casts.
>
> const int& haveANiceDay = min(4, 5);
>
>
> Andrei

But that example  actually works correctly.

TBH, most of the "unsafe" code I have been presented regarding the implict "cast + ref problem" comes from msvc accepting code which is not actually legal C++.

In "legit" C++, you *can't* bind a rvalue to a (non const) ref. gcc will turn you down if you tried any of those "unsafe" examples.
December 24, 2012
12/24/2012 9:57 PM, Jonathan M Davis пишет:
> On Monday, December 24, 2012 12:37:54 Andrei Alexandrescu wrote:
>> An important smoking gun is C++'s min(), which is allows writing unsafe
>> code without casts.
>>
>> const int& haveANiceDay = min(4, 5);
>
> But what does that have to do with const& for function parameters?

It relates directly as one may then pass the result of min to fun(const ref T);

> I can agree
> that it's bad for local variables like that, but such references aren't legal
> in D anyway - const or not. const& on function paramters merely avoids a copy,
> and as long as you don't take the reference of that parameter (which you can't
> do in D) and then assign it to something or return it, it can't survive past
> the point that it leaves scope.
>
> I get the impression that your complaints about rvalue references stem from
> issues with them that have nothing to do with function parameters, and it's
> the function parameters that everyone cares about.
>
> That being said, I don't think that having const ref take rvalues is a good
> solution for D given how strict its const is - rather I think that we should
> figure out how to make auto ref work for non-templated functions - but I fail
> to see how making const ref accept rvalues would really cause any problems.
>
> - Jonathan M Davis
>


-- 
Dmitry Olshansky