Ref local variables?

Nick Sabalausky a at a.a
Wed Jan 11 14:45:24 PST 2012


"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:op.v7xweevveav7ka at localhost.localdomain...
> On Wed, 11 Jan 2012 15:12:36 -0500, Marco Leise <Marco.Leise at gmx.de> 
> wrote:
>
>> Am 11.01.2012, 14:27 Uhr, schrieb Steven Schveighoffer 
>> <schveiguy at yahoo.com>:
>>
>>> On Tue, 10 Jan 2012 20:06:21 -0500, Ben Davis <entheh at cantab.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please excuse the cross-post with D.learn. People have been helpful 
>>>> there with workarounds, but I'm bringing it here in the hope that we 
>>>> can discuss a language enhancement.
>>>>
>>>> So - could support for 'ref' local variables be added, or is there a 
>>>> reason not to?
>>>
>>> This has been requested in the past.  In order to convince Walter, it 
>>> is helpful to examine past failed arguments.  Try a search on the 
>>> newsgroups archive.
>>>
>>> You also have to show why it's better to do it via the language than 
>>> via the library.  I think Simen's solution in the D.learn thread is 
>>> pretty compelling.
>>>
>>> -Steve
>>
>> Sorry, but it sounds plain masochistic to import a module and then 
>> instantiate a template every time you want quick access to variable in 
>> non-trivially indexed array.
>
> I disagree, this doesn't look that bad:
>
> auto tile = refOf(map[y*w+x]);
>
> If you're saying that importing a module to do this is too much, I think 
> you will have an uphill battle convincing Andrei/Walter.
>

It falls squarely into the category of "removing unnecessary restrictions in 
the langauge", which Andrei at least has said he's interested in. We already 
have ref variables: You're just currently limited to only using them as 
params. This is just simply lifting that restriction. Just like how we 
lifted the restriction of imports only being usable at the top-level of the 
AST.

Resorting to a library may allow the same feature, but it's *very* 
unorthogonal and messy, and for no real benefit. (Granted, I've never been a 
fan of obsessing over othogonality, but throwing it away for no benefit is 
no good either.)




More information about the Digitalmars-d mailing list