April 16, 2012
On Apr 16, 2012, at 2:43 PM, "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:

> On Monday, April 16, 2012 11:31:19 Sean Kelly wrote:
>> On Apr 16, 2012, at 6:32 AM, Steve Schveighoffer wrote:
>>> Regardless of the solution, I think we need to designate two different situations:
>>> 
>>> 1. I want to pass this by reference because it's more efficient 2. I want to pass this by reference because I want to change it
>> 
>> Ideally, no one should ever specify "ref" simply for efficiency. The programmer should choose semantics for logical reasons, and leave optimization up to the compiler. That may still not be practical however.
> 
> In many cases, the compiler can't know when a copy is actually required. If there's a way for the programmer to indicate that they don't care whether a copy is made or not, letting the compiler decide, then that solves the problem (which was the idea behind auto ref). Without that though, the compiler will have to assume that a copy has to be made in cases where it doesn't. And actually, since without auto ref, there's no way to overload a function such that the compiler chooses ref or non-ref based on what it thinks is the most efficient, I don't see how the compiler could elide copies except in cases where inlining eliminates the function call entirely. We need a way for the programmer to be able to tell the compiler that they don't care whether the argument is passed by ref or not. Barring that, making it possible for const ref (and possibly ref) to take rvalues is probably the best that we can do.

I believe "const scope" arguments would fall into the category of not caring if a copy was made or not.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 16, 2012
On Monday, April 16, 2012 14:57:08 Jason House wrote:
> I believe "const scope" arguments would fall into the category of not caring if a copy was made or not.

scope prevents escaping references (or is supposed to anyway - I don't think that it actually does right now), and in the case of delegates, it allows the compiler to avoid allocating a closure. It's really only applicable to reference types, so no copying would be occuring anyway. The issue is when you have value types that you don't necessarily want to copy.

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

April 16, 2012
On Apr 16, 2012, at 4:48 PM, "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:

> [scope is] really only applicable to reference types, so no copying would be occuring anyway. The issue is when you have value types that you don't necessarily want to copy.

Scope isn't implemented for anything but delegates. If something is const and no references are escaped, then both a copy and pass by reference can serve the same purpose.

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

April 16, 2012
Le 2012-04-16 à 14:31, Sean Kelly a écrit :

> On Apr 16, 2012, at 6:32 AM, Steve Schveighoffer wrote:
>> 
>> Regardless of the solution, I think we need to designate two different situations:
>> 
>> 1. I want to pass this by reference because it's more efficient 2. I want to pass this by reference because I want to change it
> 
> Ideally, no one should ever specify "ref" simply for efficiency.  The programmer should choose semantics for logical reasons, and leave optimization up to the compiler.  That may still not be practical however.

The compiler can't decide by itself because there is not enough context, it also pose some problems for having a stable ABI. That said, I agree that having to add ref (or auto-ref) everywhere for efficiency isn't very appealing.

Did you notice the "ref struct" proposal I made a while ago on the newsgroup? Basically you attach a flag to a struct declaration that'd cause that struct to be automatically passed by ref when used as a function argument. It's crude, but it'd be much less verbose than writing 'ref' or 'auto ref' everywhere.


-- 
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

April 16, 2012
On 4/16/12 4:21 PM, Michel Fortin wrote:
> Did you notice the "ref struct" proposal I made a while ago on the
> newsgroup? Basically you attach a flag to a struct declaration that'd
> cause that struct to be automatically passed by ref when used as a
> function argument. It's crude, but it'd be much less verbose than
> writing 'ref' or 'auto ref' everywhere.

Walter convinced me a while ago that transparent pass by ref is problematic. Consider:

struct S @pass_by_ref(true)
{
   ...
}

void fun(T)(T a, T b)
{
   ...
}

Inside fun, code is free to assume that &a != &b with quite important consequences. If calling fun(s, s) ends up aliasing the two names to the same thing, it will fail in difficult to figure ways.


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

1 2 3 4 5 6 7
Next ›   Last »