Thanks, I did: https://github.com/JuliaLang/julia/issues/17631
On Tuesday, July 26, 2016 at 3:32:58 PM UTC+2, Tim Holy wrote: > > 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 > > >
