actually its more about simple confusion rather than mental cost @DNF. Starting out you either use = or in then you see some other code and they use something else and wonder, what is right, is one notation faster or better, what's going on? Of course, it's not the simplest thing to try and search for in the documents (for someone not familiar with iterator terminology, searching for `in` or `=` is useless). Hence Fang's original post's concern (and others as evident from this post).
But really this seems like a fundamental enough language construct that there should be only one correct way; but on the other hand my brain doesn't have a problem with `=` and it seems natural since I have been using matlab for a while, even though `in` seems actually to make more sense here. I don't think that this metaphor is actually relevant: i=1:5 A[i]=B[i].*C[i] or, you could write it as a loop... for i=1:5 A[i]=B[i]*C[i] end since the `for` changes meaning completely i = 1:10 a[i] = b[i].*c[i] and the above only makes sense when indexing, not for other iterables In any case, someone should collect the arguments and file an issue on github to at least get some additional opinions. On Wednesday, October 28, 2015 at 8:45:16 AM UTC-4, DNF wrote: > > You are right, of course. It's just one of those minor cosmetic things you > fix in a pre-1.0 version, or then maybe never. And it's good not to have > too many of those. > > Also > for i ∈ 1:N > just looks incredibly awesome. > > > On Wednesday, October 28, 2015 at 1:38:57 PM UTC+1, STAR0SS wrote: >> >> I think people grossly exaggerate the "mental cost" of having both = and >> in. It's really not that complicated, well explained in the docs and can >> never cause bugs. >> >> On the other hand the depreciation cost will big quite large, given it >> seems both are used 50/50. Plus the numerous complain posts on this forum. >> Don't fix what's not broken. >> >> >> >>
