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