On 07/10/2012 05:07 PM, Andrei Alexandrescu wrote:
On 7/10/12 11:03 AM, Timon Gehr wrote:On 07/10/2012 05:01 PM, Andrei Alexandrescu wrote:On 7/10/12 10:32 AM, kenji hara wrote:OK. I know the past discussion about 'sealed container' so I can agree with your argument. Then I'll close the pull request.Sounds good for now but let's keep in mind the possibility of restricting ref returns. At that point we can "open up" ref returns in std.container. AndreiWould that apply to all ref returns or would there be an additional attribute that allows to explicitly restrict them?If we decide to introduce the feature it would apply to all ref parameters and results. That means functions receiving a ref parameter cannot save its address anywhere, and that callers of functions that return a ref result cannot save the address beyond the function call. Still trying to figure out whether this is too restrictive. My opinion is that that's sensible because many uses opposing it are antipatterns anyway. For example, if a function sneaks away the address of something it better makes that clear in the signature by requiring a pointer in the first place. Andrei
I am somewhat opposed to that change.
One issue is that it would make built-in arrays more magical.
struct S{ ???? }
version(A) int[] array;
version(B) S array;
auto p = &array[i];
However, the need for restricted ref returns is quite obvious.
'scope ref' ?
