"Steven Schveighoffer" <[email protected]> wrote in message news:[email protected]... > On Wed, 11 Jan 2012 15:12:36 -0500, Marco Leise <[email protected]> > wrote: > >> Am 11.01.2012, 14:27 Uhr, schrieb Steven Schveighoffer >> <[email protected]>: >> >>> On Tue, 10 Jan 2012 20:06:21 -0500, Ben Davis <[email protected]> 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.)
