foreach ref very broken: fails to call front(val)

Timon Gehr timon.gehr at gmx.ch
Tue Jul 10 15:22:11 PDT 2012


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.
>>>
>>> Andrei
>>
>> Would 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' ?


More information about the Digitalmars-d mailing list