On Tue Aug 30 11:46:53 2016, [email protected] wrote: > The trap comes from the fact that `..` and `...` with a Str endpoint > *don't* use .succ/.pred: > > "35".."40" # does something weird (and IMO useless) that is different > from .succ
Agreed, that's weird. I'm unsure why it's counting down and is indeed "too smart" for what I'd expect it to do. On Tue Aug 30 14:06:21 2016, [email protected] wrote: > Um… since when we started to blame users for not using type > constraints? I > mean, wasn't it supposed to be optional? The language should not do > stupid > things if I decided not to use type constraints, and sure enough it > does not do > stupid things when it comes to all other operators, except .. and ... It doesn't do "stupid things" with the .. operator either. I refrained from mentioning it earlier, but I think it would result in a more productive conversation if you did not assume the current behaviour was created by a boiled potato randomly bouncing up and down on a keyboard, calling it a "WAT" and a "stupid thing." The current behaviour is at least in part useful. If you think different behaviour is more understandable and more useful, you can justify it without demeaning the work that went into implementing the current behaviour. Types are there to catch type bugs, which is what the original user experienced by expecting a string to be operated on the same as a number contained within it. If you want to avoid types, you pay the price in uncaught type bugs. I'm not above "blaming users" for being burnt because they failed to user a language feature. > I mean, am I reading it wrong or something? It tells me that it is > using .succ I agree, the documentation can expound the templating behaviour on ranges with strings. I tried looking at speculations and they too appear to be sparse on the behaviours in strings with more than one character. > We can schedule it for 9.d or whatever. I don't see why changing the > behavior > of something that is of questionable usefulness should be such a big > NO. Let's > fix the language instead. So far, three core developers [^1][^2] think there's nothing to fix. My personal view is that it doesn't matter if it's a 9.d or a 42.d; breaking backwards compatibility should come with benefits, and I see none with this RFC. [1] http://irclog.perlgeek.de/perl6-dev/2016-08-30#i_13118518 [2] http://irclog.perlgeek.de/perl6-dev/2016-08-30#i_13118542 > > to limit usefulness of .. > > That's a good remark! Has anybody seen this stringy behavior being > used > somewhere in the wild? You know, maybe I'm proposing a removal of some > extremely useful feature. I'd love to see some real world examples > (something > we should be able to have by now, I guess?). I already pointed out the templating behaviour to obtain non-clobbering filenames. It's useful when creating unique files based on user file uploads. The templates can also be used to evaluate if a given value fits a template. Is that not "real world" enough? > > > • Addition of 4 extra operators that very poorly represent the > > behaviour they are meant to perform. > > I agree with Sam. Let's just throw it away. So what would provide the .succ behaviour for objects if the RFC, as I understand it now, aims to abolish the .succ behaviour entirely. > > > Introduced inconsistency between .. and … > > Here you are completely right. If we are fixing ｢..｣, then ｢...｣ > should be > fixed as well. I didn't mention it in my first message, but please > don't think > that I'm saying that we should introduce inconsistencies. Fixed how? So far you mentioned the strings do "stupid things" and I see Sam mentioning that we don't want the coersion to Numeric. So what *is* the proposed behaviour? The question applies to numerics, strings, custom objects, WhateverCodes, and Subs. ---------------------------------------------------- So far I think the original RFC to make .. a numeric operator is out. There's still an issue with .. not using .succ on strings. Does anyone know why that is the case? The templating example I presented is still valid with the pure .succ behaviour.
