On Thursday, 25 June 2015 at 13:35:30 UTC, Vladimir Panteleev wrote:
> 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.

That seems like a reasonable idea for the cases where we really don't have a noun to act as the one doing the action. The situation is weird enough with uppercase and lowercase, since you end up with stuff like upperCaser and lowerCaser when caser isn't really a thing, but at least there, we at least have a fake noun that makes sense. For the path ones, I don't see any kind of noun that makes sense. So, asAbsolutePath, etc. definitely makes some sense, so maybe asLowerCase and asUpperCase would make more sense too. In general though, I'd prefer that we go with the noun naming scheme - particularly when they're basically constructors for ranges. But it obviously doesn't work in all cases.

- Jonathan M Davis

On Thursday, 25 June 2015 at 14:10:45 UTC, Vladimir Panteleev wrote:
> And, IMHO, this:
>
> fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
>
> looks much better than this:
>
> fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))

Well, I have to disagree there, particularly when the "er" version of things is much more indicative of what's actually going on (a series of constructor calls, really - they're just done via wrapper functions). I can get behind the "asXxx" scheme when the "xxxer" scheme doesn't fit, but in general, I think that going with the "xxxer" scheme fits in very well with what's actually going on and will thus actually help make the code clearer, whereas I really don't think that that's the case with "xxxed".

- Jonathan M Davis

On 6/25/15 7:10 AM, Vladimir Panteleev wrote:
> And, IMHO, this:
>
> fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
>
> looks much better than this:
>
> fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))

I agree with Jonathan that the latter is clearer as to what the method is doing--constructing something that will do the work. However, I agree that the former reads much better. My bikeshed is painted the former way, mainly because it encourages people to use the range-based style because it reads so well.

With that said I'm hopeful that Adam's trick will obviate at least some of this discussion.

On Thursday, 25 June 2015 at 10:53:45 UTC, Vladimir Panteleev wrote:
> On Wednesday, 24 June 2015 at 21:06:43 UTC, deadalnix wrote:
>>> I'd like to raise concern about the Arguments name in std.meta . That is not the first time I do so, but this still needs to change.
>
> I haven't participated with the discussion but I agree with the points in your post.
>
>>> I discussed various names with many at DConf. The name that seemed to be, if not preferred by all, the one that nobody had any strong reason to be against is Sequence. Can we use that ?
>
> There is std.range.Sequence, though.
>
>> Also, I'm not sure why TypeTuple is introduced in std.meta "for legacy compatibility" as the module is brand new.
>
> I think it can be moved back to std.typetuple?

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

Let's see what the autotester think about this.

On Thursday, 25 June 2015 at 17:21:49 UTC, deadalnix wrote:
> https://github.com/D-Programming-Language/phobos/pull/3440
>
> Let's see what the autotester think about this.

Well, that didn't take long. But at least it uncovered a DMD ICE :)

On Thursday, 25 June 2015 at 17:23:17 UTC, Vladimir Panteleev wrote:
> On Thursday, 25 June 2015 at 17:21:49 UTC, deadalnix wrote:
>> https://github.com/D-Programming-Language/phobos/pull/3440
>>
>> Let's see what the autotester think about this.
>
> Well, that didn't take long. But at least it uncovered a DMD ICE :)

I got it to work now :)

This ICE still needs to be fixed.

On 6/25/15 6:53 AM, Vladimir Panteleev wrote:
> On Wednesday, 24 June 2015 at 21:06:43 UTC, deadalnix wrote:
>>> I'd like to raise concern about the Arguments name in std.meta . That
>>> is not the first time I do so, but this still needs to change.
>
> I haven't participated with the discussion but I agree with the points
> in your post.

Me too. Looking at Amaury's PR, there is still much of the documentation that refers to TypeTuple. It will be difficult/awkward to change to "Arguments". e.g.:

Returns an Arguments [instance] created from TList with the first occurrence, if any, of T removed.

--------

Filters an Arguments [instance] using a template predicate. Returns an Arguments [instance] of the elements which satisfy the predicate.

I think you are going to have to add "instance" anywhere you are talking about Arguments. And that "Arguments instance of" reads terrible.

I don't know what the right name is, but I think it should be singular at least.

-Steve

On Thursday, 25 June 2015 at 18:04:49 UTC, Steven Schveighoffer wrote:
> I don't know what the right name is, but I think it should be singular at least.

Part of the core problem is that it can be used for either parameters or arguments - or it can simply be used in certain places as a compile-time entity separately from functions are templates (e.g. foreach). So, names like ParamList or ArgList come to mind, but they all have the problem of covering only one of the cases (just like TypeTuple has the problem of only covering the case where it has types in it when in fact it can have values in it as well as containing both at the same time). I don't think that I've ever seen a _good_ name for what TypeTuple represents. I really wish that we'd stop using the word tuple in regards to them though, since they _aren't_ tuples. But unfortunately, that's how the language spec refers to them...

IIRC, Adam Ruppe defined them as being a CTList in his dconf talk (presumably for compile-time list). That seems like one of the better names that I've seen, and I'd certainly be up for that.

- Jonathan M Davis

On Thursday, 25 June 2015 at 18:04:49 UTC, Steven Schveighoffer wrote:
> On 6/25/15 6:53 AM, Vladimir Panteleev wrote:
>> On Wednesday, 24 June 2015 at 21:06:43 UTC, deadalnix wrote:
>>>> I'd like to raise concern about the Arguments name in std.meta . That
>>>> is not the first time I do so, but this still needs to change.
>>
>> I haven't participated with the discussion but I agree with the points
>> in your post.
>
> Me too. Looking at Amaury's PR, there is still much of the documentation that refers to TypeTuple. It will be difficult/awkward to change to "Arguments". e.g.:
>
> Returns an Arguments [instance] created from TList with the first occurrence, if any, of T removed.
>
> --------
>
> Filters an Arguments [instance] using a template predicate. Returns an Arguments [instance] of the elements which satisfy the predicate.
>
> I think you are going to have to add "instance" anywhere you are talking about Arguments. And that "Arguments instance of" reads terrible.
>
> I don't know what the right name is, but I think it should be singular at least.
>
> -Steve

I can do another PR to change the name. Let's already get the TupeTuple in the old module and remove it from std.meta so at least this monstrosity stay contained.

On 6/25/15 6:31 AM, Vladimir Panteleev wrote:
> 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

Is that the function that just takes a few values? isOrdered(0, x, 100) is a bit grating seeing as the grammar requires "are ordered". -- Andrei