On 6/23/2015 4:49 PM, Vladimir Panteleev wrote:
> IMHO, in this case, the "Lazy" suffix is a distracting technicality that doesn't
> carry its weight. Am I the only one?

Nope. For the reasons you mentioned.

On Tuesday, 23 June 2015 at 22:51:08 UTC, Vladimir Panteleev wrote:
> Proposed new name: withExtension

I'm fine with withExtension. Certainly, I don't think that anything starting with "set" really makes sense given that it's a lazy operation.

- Jonathan M Davis

On Wednesday, 24 June 2015 at 03:29:28 UTC, Walter Bright wrote:
> On 6/23/2015 4:49 PM, Vladimir Panteleev wrote:
>> IMHO, in this case, the "Lazy" suffix is a distracting technicality that doesn't
>> carry its weight. Am I the only one?
>
> Nope. For the reasons you mentioned.

Agreed. It would be horrible to be putting Lazy on the end of all of the lazy stuff. If we were doing all of the names from scratch then maybe it would make sense to slap Eager on the end of the eager ones on the theory that the lazy ones should be preferred, but even that's pretty ugly. However, if we were doing it from scratch, we probably wouldn't even _have_ most of the eager functions. Regardless, let's not add Lazy to any of these function names.

- Jonathan M Davis

On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote:
> On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
>> A rename can be proposed by creating a subthread: [...]
>
> Rationale:
>
> As with setExt, std.uni already contains functions called toLower/toUpper, thus the only difference in name is that the implied word "Case" is omitted. The distinction is not memorable.
>
> Proposed new name: lowerCased / upperCased

If we want to be consistent with the likes of splitter, then they should be something more like lowerCaser and upperCaser (though caser isn't really word, and AFAIK, there is no noun for something which changes the case of a letter). When adding lazy versions in the past, for better or worse, we've generally gone for using nouns, whereas you're suggesting adjectives based coming from the past tense of a verb (though the verb "to case" has nothing with the case of letters).

I'm not really a fan of having both toLower/toUpper and toLowerCase/toUpperCase - especially when the longer version is the lazy one - but lowerCased and upperCased are both ugly and don't follow any kind of convention that we've been using and don't follow a convention that I think we should use. Much as functions are normally verbs, it makes far more sense to me to have a function named after a noun than an adjective if it's returning a lazy range, since then you're essentially naming the function after the range (like a constructor).

So, if we're going to be more consistent, I think that following what we've done with splitter makes more sense, and while that's ugly in this case, what you're suggestion is just as ugly. And I think that I'd rather see the annoyance of having toLower/toUpper and toUpperCase and toLowerCase in the same module than start naming functions after adjectives - especially when the resulting name is ugly like it is here.

- Jonathan M Davis

On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
> Moreover, with this, some old code will *automatically* be upgraded to laziness without needing to change at all too. Tell me that doesn't at least tempt you!

I very much like this approach. I don't know that it'll work in the general case with the rangification of Phobos functions that don't currently return ranges, but in each case that it does work, it'll remove the need for distinguishing between function names, and it may allow us to make them completely lazy later - especially if some of what Walter was discussing at dconf with regards to automatically converting ranges to arrays when appropriate was implemented (e.g. when the range was assigned to an array).

And even better, every time that we go with this approach, we remove a bike shedding debate. :)

- Jonathan M Davis

On Wed, Jun 24, 2015 at 05:24:26AM +0000, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
> >Moreover, with this, some old code will *automatically* be upgraded to laziness without needing to change at all too. Tell me that doesn't at least tempt you!
> 
> I very much like this approach. I don't know that it'll work in the general case with the rangification of Phobos functions that don't currently return ranges, but in each case that it does work, it'll remove the need for distinguishing between function names, and it may allow us to make them completely lazy later - especially if some of what Walter was discussing at dconf with regards to automatically converting ranges to arrays when appropriate was implemented (e.g. when the range was assigned to an array).
> 
> And even better, every time that we go with this approach, we remove a bike shedding debate. :)
[...]

Whoa. Adam, you just blew my mind. *This* would be what I call effective use of the current language!

A solid +1 from me.


T

-- 
Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn

On Tue, 23 Jun 2015 22:51:06 +0000, Vladimir Panteleev wrote:

> Proposed new name: withExtension

+1

On Tue, 23 Jun 2015 22:58:30 +0000, Vladimir Panteleev wrote:

> Proposed new name: lowerCased / upperCased

+1 to this or https://github.com/D-Programming-Language/phobos/pull/3243

On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis wrote:
> So, if we're going to be more consistent, I think that following what we've done with splitter makes more sense, and while that's ugly in this case, what you're suggestion is just as ugly. And I think that I'd rather see the annoyance of having toLower/toUpper and toUpperCase and toLowerCase in the same module than start naming functions after adjectives - especially when the resulting name is ugly like it is here.
>
> - Jonathan M Davis

If nouns are the convention we want, then one option might be to just introduce one function "capitalizer" and have the case type be an additional argument to the function, aka: capitalizer!lower/ capitalizer!upper/ capitalizer!title. Or lowerCapitalizer/ upperCapitalizer might work as well.

setExtension would then obviously translate to extensionSetter. Though adams idea also seems very good but with the drawback of some broken code.

On Wednesday, 24 June 2015 at 00:16:49 UTC, Tofu Ninja wrote:
> But now you are going to have to come up with a clever name for every replacement and the clarity of each will be shoty at best. The append lazy convention at least is a convention that is very clear, the other way has no rules, you just are making up new names.

A UFCS chain of functions full of the word 'lazy' is going to look pretty clunky.

auto gubbins = guns.setStuffLazy.doMoreThingsLazy.turnOnLasersLazy.fireLasersLazy.coolLasersLazy;

Would using the same names be a possibility for lazy and eager functions? At least going forward. Default to lazy and instantiate as eager otherwise. Is it possible to make a meta template that would instantiate all functions in a chain as lazy or eager as desired?

setExt!"eager" and setExt