On Monday, April 09, 2012 19:40:43 Walter Bright wrote:
> On 4/9/2012 7:32 PM, Nick Sabalausky wrote:
> > Although, if there really is good merit to struct lits not veing lvalues, then maybe all we need is to wait until "auto ref" is usable for non-templates? (If that would even be possible...?)
> 
> Not possible, as the binary ABI would be different.

It was my understanding that the auto ref was supposed to work with non- templated functions - at least what Andrei proposed was - but that you misunderstood that and made it only work with templates. And as long as it only works with templates, it's usefulness is very limited. opEquals would be a _prime_ case for where it would be useful.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/9/12 9:42 PM, Jason House wrote:
> From a safety perspective, passing strict literals as "const ref" is
> fine. There is no output to discard. I have a vague impression that
> the restriction was put in place to allow some kind of optimization.
> I bet it's discussed in TDPL somewhere...

Rvalues masquerading as references to constant values have caused enormous harm to C++, culminating in the "fix" that was rvalue references.

Let's not repeat that values. Rvalues are rvalues and should stay that way.

What is in essence the problem to be solved? My understanding is that a thunk function would be appropriate here.


Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Apr 9, 2012, at 10:46 PM, Andrei Alexandrescu <andrei@erdani.com> wrote:

> On 4/9/12 9:42 PM, Jason House wrote:
>> From a safety perspective, passing strict literals as "const ref" is fine. There is no output to discard. I have a vague impression that the restriction was put in place to allow some kind of optimization. I bet it's discussed in TDPL somewhere...
> 
> Rvalues masquerading as references to constant values have caused enormous harm to C++, culminating in the "fix" that was rvalue references.
> 
> Let's not repeat that values. Rvalues are rvalues and should stay that way.

I have never seen an explanation of D's  lack of rvalue references longer than this. Is there any online explanation/blog describing how this neatly avoids the need for the solution from C++? There has to be more to it than just creating a temporary variable when the compiler issues an error.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/9/2012 7:44 PM, Jonathan M Davis wrote:
> On Monday, April 09, 2012 19:40:43 Walter Bright wrote:
>> On 4/9/2012 7:32 PM, Nick Sabalausky wrote:
>>> Although, if there really is good merit to struct lits not veing lvalues,
>>> then maybe all we need is to wait until "auto ref" is usable for
>>> non-templates? (If that would even be possible...?)
>> Not possible, as the binary ABI would be different.
> It was my understanding that the auto ref was supposed to work with non-
> templated functions - at least what Andrei proposed was - but that you
> misunderstood that and made it only work with templates. And as long as it
> only works with templates, it's usefulness is very limited. opEquals would be
> a _prime_ case for where it would be useful.
>

How could that possibly work for the same function, considering that the code for each would be quite different, including the calling code?

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Monday, April 09, 2012 20:55:16 Walter Bright wrote:
> On 4/9/2012 7:44 PM, Jonathan M Davis wrote:
> > On Monday, April 09, 2012 19:40:43 Walter Bright wrote:
> >> On 4/9/2012 7:32 PM, Nick Sabalausky wrote:
> >>> Although, if there really is good merit to struct lits not veing
> >>> lvalues,
> >>> then maybe all we need is to wait until "auto ref" is usable for
> >>> non-templates? (If that would even be possible...?)
> >> 
> >> Not possible, as the binary ABI would be different.
> > 
> > It was my understanding that the auto ref was supposed to work with non- templated functions - at least what Andrei proposed was - but that you misunderstood that and made it only work with templates. And as long as it only works with templates, it's usefulness is very limited. opEquals would be a _prime_ case for where it would be useful.
> 
> How could that possibly work for the same function, considering that the code for each would be quite different, including the calling code?

I don't know. When it came up semi-recently in the newsgroup, Timon had a suggestion, but I don't recall what it was.

Heck, it could simply duplicate the function outright. That's what we're going to be forced to do with pretty much every single const ref function anyway. It may be that making const ref take temporaries really is a bad idea, but without that, it's very nearly useless IMHO. Certainly, any time that you use it, you have to declare a version which doesn't take a ref or the function will only work with lvalues, which is almost always overly restrictive. So, having auto ref simply duplicate the function would still be a big step forward. For example

void func(auto ref S s)

could become

void func(ref S s)
void func(S s)

and

void func(const auto ref S s)

could become

void func(const ref S s)
void func(const S s)

The non-ref version could then call the ref version and avoid having to duplicate the entire function body. It's what we're going to have to be doing by hand for const ref functions anyway.

Having to duplicate pretty much every single function which takes a const ref - opEquals and opCmp being very prominent among them - is a definite problem. That's the problem that auto ref was intended to solve, and as long as it only works with templated functions, it really doesn't solve the problem.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Le 2012-04-10 à 0:06, Jonathan M Davis a écrit :

> Having to duplicate pretty much every single function which takes a const ref - opEquals and opCmp being very prominent among them - is a definite problem. That's the problem that auto ref was intended to solve, and as long as it only works with templated functions, it really doesn't solve the problem.

I think the implementation of auto-ref you want is one where the argument is always passed by ref but it the function would also accept lvalues. I think "auto ref" is a misnomer for that.

Actually, I think the true problem you are trying to solve using auto-ref is one of efficiency: you don't want all structs to be passed by copy because often that'd be inefficient. Disregarding efficiency, all cases where you want to use auto-ref you could pass the struct by copy instead. Am I right?

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/



_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Tuesday, April 10, 2012 00:39:26 Michel Fortin wrote:
> Le 2012-04-10 à 0:06, Jonathan M Davis a écrit :
> > Having to duplicate pretty much every single function which takes a const ref - opEquals and opCmp being very prominent among them - is a definite problem. That's the problem that auto ref was intended to solve, and as long as it only works with templated functions, it really doesn't solve the problem.
> I think the implementation of auto-ref you want is one where the argument is always passed by ref but it the function would also accept lvalues. I think "auto ref" is a misnomer for that.
> 
> Actually, I think the true problem you are trying to solve using auto-ref is one of efficiency: you don't want all structs to be passed by copy because often that'd be inefficient. Disregarding efficiency, all cases where you want to use auto-ref you could pass the struct by copy instead. Am I right?

Yes, assuming that you're not dealing with a struct which isn't copyable. In C++, you use const& for objects to avoided unnecessary duplication. But that doesn't work in D, since const ref won't take rvalues. So, you're forced to duplicate the function. Also, some functions have historically required const ref (e.g. opEquals), but I don't know if they do now or not.

The whole point of auto ref is to have the compiler take the argument in the most efficient manner - be it by ref or by value; you don't care which. But it only works with templated functions right now, so it doesn't really solve the problem.

I really don't care how it's implemented for not-templated functions. It can be the outright equivalent of C++'s const& for all I care. But without auto ref on non-templated functions, we're forced to duplicate any non-templated function which takes const ref.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 10 April 2012 05:05, Jason House <jason.james.house@gmail.com> wrote:
> On Apr 9, 2012, at 10:46 PM, Andrei Alexandrescu <andrei@erdani.com> wrote:
>
>> On 4/9/12 9:42 PM, Jason House wrote:
>>> From a safety perspective, passing strict literals as "const ref" is fine. There is no output to discard. I have a vague impression that the restriction was put in place to allow some kind of optimization. I bet it's discussed in TDPL somewhere...
>>
>> Rvalues masquerading as references to constant values have caused enormous harm to C++, culminating in the "fix" that was rvalue references.
>>
>> Let's not repeat that values. Rvalues are rvalues and should stay that way.
>
> I have never seen an explanation of D's  lack of rvalue references longer than this. Is there any online explanation/blog describing how this neatly avoids the need for the solution from C++? There has to be more to it than just creating a temporary variable when the compiler issues an error.

I haven't seen any longer explanation, either. We seem to be in a situation where there's a problem, the only known 'solution' (from C++) has been rejected, but without a replacement.

For nearly two years it has been one of the top items on my list of
outstanding compiler and language issues:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#DMDCompilerStability
It needs considerable thought, and a complete description of what's
wrong with the C++ approach seems to be a necessary and useful step.
BUT... I don't think we should be trying to solve this difficult issue
right now, while we are trying to get a release out the door.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Tuesday, April 10, 2012 08:16:42 Don Clugston wrote:
> BUT... I don't think we should be trying to solve this difficult issue right now, while we are trying to get a release out the door.

Of course not. We're stuck with duplicating const ref functions for now just like we have been. Recent changes to opEquals and opCmp just highlight it. But it _is_ something that we need to solve. To the layman at least, C++'s solution seems far superior to D's insistance that const ref actually be a ref. Apparently, there's a good reason not to, but most of us don't really understand it. Andrei is very passionate about it though.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 4/9/2012 10:51 PM, Jonathan M Davis wrote:
> I really don't care how it's implemented for not-templated functions. It can be the outright equivalent of C++'s const& for all I care. But without auto ref on non-templated functions, we're forced to duplicate any non-templated function which takes const ref.

Let's say the compiler auto-generates the following:

   void foo(T t) { foo(t); }

in case it sees:

    void foo(ref T t) { ... }

I don't think that's a solution at all. It's just a roundabout way for the compiler to generate a temporary anyway. Nothing has been gained.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta