There's a specific reason why length was deprecated, and the error, which gives alternatives, may give some insight:
# perl6 -e 'my $string = "foo"; say length $string;'
===SORRY!=== Error while compiling -e
Undeclared routine:
length used at line 1. Did you mean 'elems', 'chars', 'graphs', 'codes'?
Perl 6 tries to get unicode right. In doing so, it makes a distinction between characters, elements, codepoints and graphemes. At certain points, you may want one or the other of these.
When asking for the length of a string, what are you really asking for? The number of characters? Visible characters, or unicode combining characters? What if it's really the number of bytes in the string you need? Perl 6 makes it easy to determine all of these things in a clear manner. In doing so, it becomes obvious that "length" is ambiguous due to both its common specific role in other languages, and it's meaning when viewed in the context of these different needs.
If you want individual characters, you split the string, if you want access to the underlying data, you call .encode to get the encoding you expect, or you stick it into a Buf or Blob type if you don't actually need string semantics.
(Corrections welcome, I could be wrong at any number of points above).
That does shed some insight into why a generic Length is missing, but I agree with the sentiment that it is counter intuitive. It does not read right on a quick scan, and I think this is especially important in softly typed languages.
If I see string.chars I expect to see a bucket of char, and not the count of chars. That name needs to be more explicit.
I think you are speaking from unfamiliarity with the language and possibly bringing baggage from other languages. In Perl 6, chars is the number of characters in a string, and elems, which is inherited from the Any role, exists on many objects and means the number of elements, as that makes sense for that object.
Perl 6 is not softly typed, it's gradually typed. It's as hard as you want to make it.
> If I see string.chars I expect to see a bucket of char
Why? Is that an expectation that comes from some other language? There's only so much you can expect a language to follow the semantics of other languages. Perl 6 will have it's own quirks, expecting it to conform to some malleable standard based on what some percentage of other languages do is not something I think is entirely fair to expect.
> Why? Is that an expectation that comes from some other language?
No, the convention that (thing that can be viewed as a collection of subelements in several different ways).(plural name for one kind of subelement) is a property/method providing a collection of the subelements of the named type is not only common in other languages, it is also quite common in Perl 6 -- and even followed (aside from chars) in the Str class specifically; examples include (from Str): univals, lines, words, ords
chars is the odd man out here: charcount or something similar would have been a lot cleaner. (Yes, its consistent with elems, but that seems to be poorly chosen for the same reason; its a plural name, but it provides a single numeric value.)
In the code I'd make I'd always call these nchars and nelems and it would be intuitively clear (to me too one year after I wrote the code), but Perl 6 seems to like to mess with the accustomed minds. Renaming "for ( ; ; )" which was structurally identical to the C one to the "loop" is easy. Somebody also mentioned renamed ARGV to *ARGS. Examples aplenty.
It seems this and a lot of other details were intentionally made to clash with our habits, as I write in my other comment.
I don't necessarily disagree with your reasoning, but I vaguely recall there was quite a bit of debate about the naming of these methods when they changed, and I don't recall the arguments. I have a feeling it's too late to change them now, so it may just have to live on as a quirk of the language.
If I had been part of the effort, I would have suggested nchars, nelems, etc. chars and elems sounds to me also like I'm going to get a collection of some kind.
This word is banned in Perl 6. You must specify units. In practice, this probably means you want Str.chars(), although it could be Str.bytes(), or even something else. See S32-setting-library/String for details."
That's an interesting design decision, and I suppose it solves the Python problem of "I want to operate on any iterable, except for strings which are technically iterables but I want to treat them as atomic elements."
(Incidentally, does Python 3 have a solution to this problem?)
Every Perl expression has a context, and context is as central to Perl as types are to some other languages. It's first chapter material in any Perl book. It's not "overloading on return type" strictly speaking, but that's what the syntax looks like.
An array (of characters in your example) in a scalar context is the length of the array. I don't know if that's whats happening here, but that's how you do it everywhere else in Perl so it would make sense to do it on strings too.
Perl6 doesn't do this. A function doesn't know if it's being called in scalar or list context.
(I think there might be some movement towards letting a function detect sink (void) context. Then functions with both side effects and return values don't need to calculate the return values when they aren't needed.)
I agree with you. I think a chars functions isn't the best name in the sense that it returns the length of the string instead of a list of its individual characters.
It makes me wonder if this will be the case for other methods in the language.
Or is that overlading on return type, and do you get the behavior I would find intuitive if one assigns to an array?
Even if that is true, I find that ugly. I would prefer more explicit code, for example
Similarly: (All IMHO)