scope for array parameters
Jonathan M Davis
jmdavisProg at gmx.com
Tue Sep 4 15:27:47 PDT 2012
On Tuesday, September 04, 2012 23:42:33 bearophile wrote:
> Jonathan M Davis:
> > Once scope is properly enforced, then optimizing based on it
> > would be great, but until it is, it's a _bad_ idea.
>
> Today we use "in" often for function arguments, and it implies
> "scope". Surely some of those programs use the arguments wrongly,
> this means they probably sometime escape. So are those programs
> someday going to become compilation errors? For the "-property"
> and for the arguments of delegate/function pointers the idea of
> turning some code currently used in errors is failing...
> Such things need to be implemented early in a language.
That's part of why I keep saying not to use in whenever it comes up. scope is
very broken, so in is very broken. And honestly, given how often arrays are
used in structs, I suspect that it's not at all uncommon for in to be used
incorrectly.
I'd actually argue to _never_ to use in at this point. If you want const, then
use const. If you want scope, then use scope. But using scope on anything
which isn't checked properly by the compiler is just asking for it. You _will_
have code that breaks when scope is fixed. I believe that the only case that
has _any_ protection at all with scope right now is delegates, which almost
never should be const. So, using in makes little to no sense to me.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list