In continuation of the "Naming things" thread, Andrei proposed the following plan:

[andralex] 1. Collect all names ADDED to Phobos since 2.067
[andralex] these are names that we have ONE shot in eternity to get right before they’re frozen
[andralex] 2. Lead a community discussion on choosing the most palatable names
[andralex] 3. We freeze those names in 2.068 and there’s no more discussion about them

So, here's a diff of sorts of public names between 2.067.1 and git master:

http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff

Created using: https://gist.github.com/CyberShadow/e088c1f2bbfc24f2bbba

As we can potentially argue forever about names, I would like to propose the following plan of action:

1. Establish a list of names that have to be changed. (If there's no consensus on a particular name, the name stays.)

2. Choose new names. If there's no consensus, I'll pick a name from the suggested ones, focusing on consistency. (Not entirely happy about this, but I think it's the lesser evil.)

3. Change the names, with 2.068.0 RC1 being the deadline. I'll create and will be updating a PR after the first beta, and ask the release manager to merge it before the RC release.

A rename can be proposed by creating a subthread: reply to this post, but change the name to the fully-qualified name of the identifier you'd like to see renamed. Please include a rationale and a proposed new name in your post. I'll start.

Sounds good?

On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
> A rename can be proposed by creating a subthread: reply to this post, but change the name to the fully-qualified name of the identifier you'd like to see renamed. Please include a rationale and a proposed new name in your post. I'll start.

Rationale:

std.path.setExt is the lazy (range-based) version of std.path.setExtension, thus the only difference in the name is that one is abbreviated, and the other is not. As there is no consistent convention that abbreviated names are lazy, it is not memorable which function is which.

I presented a case in my earlier thread (point 6):

http://forum.dlang.org/post/pnzrkgxkxprsgppxkdyp@forum.dlang.org

Proposed new name: withExtension

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

`setExtensionLazy`

Rationale
* sorts well with `setExtension` for tooling
* implies that it is related to `setExtension` in some way
* at-a-glance disambiguates it from `setExtension` with a clue as to how it is differrent

The disadvantage is that its a little long, but that's due to the length of "Extension" not the "Lazy" suffix.  If it's a problem simply create `setExt` and `setExtLazy` and have `setExtension` forward to `setExt`for backward compatibility with a friendly comment.  It wouldn't even need to be deprecated.

Mike

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

I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too "clever" and really just ends up causing unnecessary confusion. This is not Ruby.
[1]https://msdn.microsoft.com/en-us/library/hh191443.aspx

`toLowerLazy`/`toUpperLazy`

Rationale
* sorts well with `toUpper/Lower` for tooling
* implies that it is related to `setUpper/Lower` in some way
* at-a-glance disambiguates it from `toUpper/Lower` with a clue as to how it is differrent

Mike

On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
> 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
>
> I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too "clever" and really just ends up causing unnecessary confusion. This is not Ruby.
> [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx

Yes please! If I didn't know what they were replacing, I would have no idea what withExtension, lowerCased, or upperCased meant at all. They hardly seem better than what they are replacing. Just do setExtensionLazy / toLowerLazy / toUpperLazy. It is much simpler and clearer.

On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:

> Sounds good?

Yes, please note that although I suggested a `Lazy` suffix, I don't want it to be a convention.  It should only be used as a disambiguator when ambiguity arises.

Mike

On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
> I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too "clever" and really just ends up causing unnecessary confusion. This is not Ruby.
> [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx

I'm not sure about this... I've seen another proposal for a "lazy" suffix in the other thread, but I think this won't be great in the long run:

- Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays.

- There is no consistency with any existing naming schemes. Currently no names in Phobos contain the word "Lazy".

- If std.algorithm were to follow this convention, it would have lazyJoin instead of joiner, lazySplit instead of splitter, lazyConcat OSLT instead of chain, etc. Given a typical program using std.algorithm, do you think such names would look better there than the current ones?

- I'm not sure about the C# async analogy: with "async", the methods are used in a different way. The new range-based functions are used in the same way, but work on different types.

Here's an example program using setExt[ension] and toLower[Case], in 4 variants...

https://gist.github.com/CyberShadow/5cc7e926f566d56a672f

IMHO, in this case, the "Lazy" suffix is a distracting technicality that doesn't carry its weight. Am I the only one?

On Tue, Jun 23, 2015 at 4:27 PM, Tofu Ninja via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
>
>> On Tuesday, 23 June 2015 at 22:58:32 UTC, Vladimir Panteleev wrote:
>>
>>>
>>> Proposed new name: lowerCased / upperCased
>>>
>>
>> I really hate this naming scheme for functions that take lazy parameters. I still don't see why we don't do the (IMO) simplest and most intuitive thing and name them lazyToLower / lazyToUpper (or toLowerLazy / toUpperLazy). ...
>
>
> Yes please! If I didn't know what they were replacing, I would have no idea what withExtension, lowerCased, or upperCased meant at all. They hardly seem better than what they are replacing. Just do setExtensionLazy / toLowerLazy / toUpperLazy. It is much simpler and clearer.
>

Counter argument:

If the lazy versions are expected to be preferred/used often, then using a 'Lazy' suffix for them is wordy and counterproductive.  You want the preferred method to be nicer than the alternative, which having extra 'Lazy' on the end isn't.

Lazy suffix smacks of lazy naming to me.


Point the first: There should be a different convention for these different methods (believe there is no argument here).

Point the second: This convention should apply throughout phobos, trying to choose on a method-by-method basis gives a crappy library.

Point the third: Pretty/intuitive range-centric names are good.  Names should reflect that this is a different approach, not just 'toFooRanged'.

TL;DR I like Vladimir's names, don't like toLowerLazy.