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
