My only goal is to provide a smooth path for catching likely bugs in "legacy" code; if people start abusing `len`, that's their own *#!$ fault. This is about protecting the innocent (people who wrote code that was perfectly fine in an earlier era), not about trying to prevent abuse.
So, I'm not against giving _length a better name and exporting it. Could you please file these concerns as an issue? It might get more attention from the right parties that way. Best, --Tim On Tuesday, July 26, 2016 5:03:31 AM CDT Oliver Schulz wrote: > > Are you saying we should export what is currently _length? > > Well, maybe not exactly length, but I believe Base should export some short > equivalent length(linearindices(A)), to encourage people to write code that > will work with both standard and custom-indexed arrays. > > In a sense (at least according to > http://docs.julialang.org/en/latest/devdocs/offset-arrays/), we're kinda > deprecating Base.length. Not explicitly, but as the recommendation is to > not support it for custom-indexed arrays, I can't use Base.length any more > if I want to write generic code. After all, I don't know if someone else > may want to use my function with a custom-indexed array. But I find that I > often do need the length of the input (e.g. for normalization), > and length(linearindices(A)) is just soo unwieldy. Of course every package > can define it's own shortcut for it - but isn't that a bit un-Julianic? Or > are you worried that people will then start using (e.g.) 1:len(A) instead > of 1:length(A), resulting in an even bigger mess? > > On Tuesday, July 26, 2016 at 1:47:57 PM UTC+2, Tim Holy wrote: > > On Tuesday, July 26, 2016 2:31:10 AM CDT Oliver Schulz wrote: > > > I should have known you already have a (very elegant) solution in your > > > pocket. :-) I really like your proposed first:last syntax! > > > > As discussed in that issue, the problem is that it may not be workable > > (it's > > also very unlikely to be merged for julia 0.5). The "safe" alternative is > > to > > modify the parser, although that has the disadvantage that you can't pass > > constructs with `start` or `end` as arguments to functions---it only works > > inside of [] brackets, which was what motivated addition of the `@view` > > macro. > > Bottom line is that we don't have a good solution to this problem at the > > moment. > > > > Interestingly, it seems likely that one could experiment with https:// > > github.com/JuliaLang/julia/pull/15750 in a package. If it becomes popular > > then > > it might help clarify whether one should move it into base. > > > > > Concerning Base._length, I was rather thinking about something for the > > > average user to use instead of length. For everyday > > > use, length(linearindices(A)) is just too unwieldy, IMHO. > > > > Are you saying we should export what is currently _length? Keep in mind > > that > > folks who want to add support for unconventional indices to their own > > packages > > can of course make this one-line definition themselves, and then they > > don't > > have to worry about whether Base will eliminate or rename it. > > > > Best, > > --Tim
