On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
> http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff

Rationale:

- The function is very closely related to "isSorted".
- The "is" prefix strongly indicates that the return value is a bool, and removes ambiguity that this function might return an ordered view of something.
- Would be nice to leave this naming scheme for lazy range operations, as is already used for indexed / transposed, which return ranges, not bools.

Suggested new name: isOrdered / isStrictlyOrdered

On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
> http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff

Rationale:

- The eager versions are called absolutePath, normalizedPath, relativePath. If anything, the current naming scheme is opposite to some options we've been discussing (e.g. eager=toLowerCase, lazy=lowerCase[d|r]).

Suggested new names: asAbsolutePath, asNormalizedPath, asRelativePath.

Couldn't think of anything better, but I think this is an improvement. If we are to adopt the "as" prefix, we could also go with asLowerCase/asUpperCase for the std.uni ones.

On 6/24/15 11:40 PM, Adam D. Ruppe wrote:
> On Thursday, 25 June 2015 at 03:12:47 UTC, Steven Schveighoffer wrote:
>> A curious thing though. All the tests for things like:
>>
>> assert(setExtension("file", "ext") == "file.ext");
>>
>> do not trigger a call to eager.
>
> But it passes? That's bizarre. (My dmd is apparently too old to compile
> this, it segfaults when I try!)

Let me clarify this -- it does not spout the deprecation for those lines. I'm not sure exactly what the compiler is doing :) is there a good way to determine how the compiler is resolving the call?

>
>> assert(setExtension("file", "ext").array == "file.ext");
>
> I did experience this in my proof-of-concept because I didn't implement
> .length. So when array checked hasLength, it found it through the alias
> this, which called eager.

Hm... it should only define length if the underlying strings satisfy hasLength. And AFAIK, strings and wstrings do not have length according to Phobos. I can do some asserts to check.

> (That's also why I did a foreach loop instead
> of just returning array(this). Well, that and the auto-decode nonsense,
> but array would be a recursive call and stack overflow anyway).

I actaully followed Walter's example and used std.conv.to :)

> These two things are weird, but I'm sure they're just bugs that we can
> handle. In the morning, I'll try a git dmd and see if I can play with it
> a little, right now I'm just guessing since it won't build on my current
> setup.

I'm interested to hear how it goes!

-Steve

On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
> http://dump.thecybershadow.net/0362443dfcca30860db907e494831b79/names.diff

Rationale: Same as toLowerCase/toUpperCase.

Suggested new name: Following the same pattern as whatever new toLowerCase/toUpperCase names will be chosen.

On 6/24/15 11:40 PM, Adam D. Ruppe wrote:

> (An interesting point here though is since alias this DOES return a
> string, any duck-type checks or implicit conversion checks will also
> pass what it passes... and work, it'll just silently allocate the
> string. Which is no regression! The status quo is it allocates that
> string EVERY time anyway. But it also isn't ideal. Someone earlier said
> we can probably apply @nogc to everything but the eager method. I think
> that'd work, and then at least the allocations wouldn't be silent
> anymore - the @nogc attribute at the call site can catch them.)

One thing that is troubling to me here is that doing an alias this to a string presents 2 range interfaces, but they are not "atomic". That is, something that is checking for elements of a range may find some properties satisfy by using the alias this, and other properties satisfy using the real type. For example, it would be alarming if it called r.eager.length to get the length, but then used the chainString to actually do a slicing operation. For this case, it's probably fine, but I never considered that alias this can present a "hybrid" between both types that may satisfy more than you want.

An interesting drawback for alias this...

-Steve

On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev wrote:
> On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis wrote:
>> 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).
>
> OK, so I didn't really understand what were you referring to, since the only examples I found while looking through the *stable* documentation were joiner and splitter. But I went through the list of new symbols, and I found that a few more have been added after the last release to std.string:
>
> en/detabber, left/right/centerJustifier, soundexer
>
> So, one option is to stay consistent with these additions, and go with upperCaser and lowerCaser, even if those sound a bit odd.
>
> Another option would be to rename those additions as well, so we would have:
>
> en/detabbed, left/right/centerJustified, soundexed, upperCased, lowerCased
>
> I don't know if this counts as being outside of the scope of this thread.
>
> Any thoughts? Or is everyone bored to death already? :)

I prefer the noun naming scheme to the adjective naming scheme. We really haven't been using adjectives much, and I think that nouns make more sense, since what you're basically doing is constructing an object. So, I'd just as soon not start using adjectives for functions which return lazy ranges.

Also, the less that we have to rename the better, so if many of the newer functions are already nouns, then it makes sense to continue that (and it wouldn't surprise me if some of the newer ones were in 2.067, in which case, it's likely too late to change them unless they're particularly bad).

- Jonathan M Davis

On Thursday, 25 June 2015 at 13:48:41 UTC, Jonathan M Davis wrote:
> I prefer the noun naming scheme to the adjective naming scheme. We really haven't been using adjectives much, and I think that nouns make more sense, since what you're basically doing is constructing an object. So, I'd just as soon not start using adjectives for functions which return lazy ranges.

What do you think of asLowerCase? I heard no objections, this one actually sounds like proper English, and it's consistent with the only better name for "toAbsolutePath" that I could think of ("asAbsolutePath").

> Also, the less that we have to rename the better, so if many of the newer functions are already nouns, then it makes sense to continue that (and it wouldn't surprise me if some of the newer ones were in 2.067, in which case, it's likely too late to change them unless they're particularly bad).

No, I'm looking at the diff of functions between 2.067 and master, and the only verb-noun names in 2.067 are "joiner" and "splitter".

On Tuesday, 23 June 2015 at 22:45:10 UTC, Vladimir Panteleev wrote:
> 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.

So, the first Beta is out.

Here's a rough tally:

--------------------------------------

std.path.setExt
  withExtension
    +3 -2
  setExtensionLazy
    +1 -1 (not counting "xLazy" objections from toLowerCase subthread)

I think withExtension is the "winner" here. There are a few arguments in favor of a "Lazy" suffix, but many arguments against.

--------------------------------------

std.uni.toLowerCase (and toUpperCase)
  lowerCased
    +2 -? (all objections seem to be regarding anything that's not "fooLazy")
  asLowerCase
    +1
  inLowerCase
    +1
  toLowerLazy
    +4 -6
  lowerCaser
    +2 -1
  lowerCase
    +1 -1
  willLowerCase
    +1

No consensus. My thoughts:

- Appending "Lazy" has been argued for, but moreso against. I think the same arguments apply to "willLowerCase".
- The goal (and reason for renaming this function in the first place) is to make the lazy name memorably distinguishable from its eager counterpart, toLower. This rules out "lowerCase".
- Taking consistency as a factor, this leaves "lowerCaser" (consistent with e.g. "joiner" and "splitter"), "lowerCased" (consistent with e.g. "transposed" and "radial"), and "asLowerCase" (consistent with the only better name for "toAbsolutePath" that I could think of).
- "asLowerCase" and "lowerCased" does sound a bit more like proper English than "lowerCaser".

I'll go with "asLowerCase" for now, but there's still time for debate.

--------------------------------------

I just went through the list and found a few more candidates. I should've done that immediately, sorry about that - with the Beta out, this leaves little time to discuss those. I created new subthreads for all of them.

Here is a draft PR:

https://github.com/D-Programming-Language/phobos/pull/3439

On Thursday, 25 June 2015 at 13:59:41 UTC, Vladimir Panteleev wrote:
> I just went through the list and found a few more candidates. I should've done that immediately, sorry about that - with the Beta out, this leaves little time to discuss those. I created new subthreads for all of them.

Forgot to mention, I added them to the wiki page for some perspective:

http://wiki.dlang.org/Naming_conventions

On Thursday, 25 June 2015 at 13:48:41 UTC, Jonathan M Davis wrote:
> Also, the less that we have to rename the better

Well, just to keep in mind, we're going to establish a convention in this release even if we do not explicitly state so - because in future naming decisions, we *will* be using precedent for consistency, as we're using now.

So, I'm not saying we *should* go back and rename almost everything added in 2.068 now, but I'm saying that we shouldn't allow these hastily-chosen initial names to be a factor in deciding how to name things from now on. I certainly wouldn't mind renaming all of them.

And, IMHO, this:

fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))

looks much better than this:

fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))