First, very good initiative.

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.

Arguments is not a good name. In the very example from the std.meta doc, Arguments is used as parameter and not as argument. I think this is naming failure just right there.

It can also be used as argument. It can be used as parameter. It can be used to build tuple. It can probably be used in way that haven't been invented yet.

Naming that thing after one of its use is a bad idea. It is generally a bad idea as future use of the concept tends to not conform with the original name and everything becomes confused.

In that specific case, it is not even future uses that will be non conformant, it is current use in the very documentation that is.

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 ?

On Wednesday, 24 June 2015 at 20:19:49 UTC, Marc Schütz wrote:
> On Wednesday, 24 June 2015 at 14:01:32 UTC, Wyatt wrote:
>> I don't think I'd interpret these two names as having the same functionality in the first place.  I'd probably learn their equivalence completely by accident and only remember it by rote.
>
> Interesting. But once you know that, it's easy to tell which is which, no?

Is it, though?  I mean I _guess_ setExtension() sounds more eager?  Familiarity removes my ability to make a first-time judgement.

But by the time I've learned of their equivalence and that one is lazy and the other is not, the API has already "lost" as far as I'm concerned.  Maybe this can be mitigated with really good docs that lists paired functions together so it's at least easy to find them.

Or here's a thought: Since we apparently want to minimise/kill eagerness, can we detect usage of eager functions and catch/flag them?  Similar in ideal to Adam's (brilliant) wrapper thing, but with tooling.  A @lazy attribute (analogous to @nogc), or a switch, or dfix rules, or something.  I don't know.

-Wyatt

On Wednesday, 24 June 2015 at 20:56:31 UTC, deadalnix wrote:
> First, very good initiative.
>
> 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.
>
> Arguments is not a good name. In the very example from the std.meta doc, Arguments is used as parameter and not as argument. I think this is naming failure just right there.
>
> It can also be used as argument. It can be used as parameter. It can be used to build tuple. It can probably be used in way that haven't been invented yet.
>
> Naming that thing after one of its use is a bad idea. It is generally a bad idea as future use of the concept tends to not conform with the original name and everything becomes confused.
>
> In that specific case, it is not even future uses that will be non conformant, it is current use in the very documentation that is.
>
> 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 ?

Also, I'm not sure why TypeTuple is introduced in std.meta "for legacy compatibility" as the module is brand new.

On Wednesday, 24 June 2015 at 20:03:35 UTC, Vladimir Panteleev wrote:
> Well, I suppose simply "upperCase" and "lowerCase" are an options, if you squint your eyes and pretend they're verbs.

The opposite of "lowerCase" would be "raiseCase". ;)

(Huh, "transposeCase"?)

-Wyatt

On 6/24/15 5:06 PM, deadalnix wrote:
> On Wednesday, 24 June 2015 at 20:56:31 UTC, deadalnix wrote:
>> First, very good initiative.
>>
>> 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.
>>
>> Arguments is not a good name. In the very example from the std.meta
>> doc, Arguments is used as parameter and not as argument. I think this
>> is naming failure just right there.
>>
>> It can also be used as argument. It can be used as parameter. It can
>> be used to build tuple. It can probably be used in way that haven't
>> been invented yet.
>>
>> Naming that thing after one of its use is a bad idea. It is generally
>> a bad idea as future use of the concept tends to not conform with the
>> original name and everything becomes confused.
>>
>> In that specific case, it is not even future uses that will be non
>> conformant, it is current use in the very documentation that is.
>>
>> 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 ?
>
> Also, I'm not sure why TypeTuple is introduced in std.meta "for legacy
> compatibility" as the module is brand new.

std.meta was moved from std.typetuple, and it now publicly imports std.meta.

-Steve

On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
> We disagreed on this on irc, but I ask you to consider the following which limits the code breakage a lot more than my first proposal in chat:
>
> [...]

Couldn't this even be made @nogc by just applying it to eager()?

Very neat. I love it.

On Wednesday, 24 June 2015 at 22:11:03 UTC, Brad Anderson wrote:
> On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:
>> We disagreed on this on irc, but I ask you to consider the following which limits the code breakage a lot more than my first proposal in chat:
>>
>> [...]
>
> Couldn't this even be made @nogc by just applying it to eager()?
>
> Very neat. I love it.

Err, everything but eager.

On Wednesday, 24 June 2015 at 21:53:25 UTC, Steven Schveighoffer wrote:
>> Also, I'm not sure why TypeTuple is introduced in std.meta "for legacy
>> compatibility" as the module is brand new.
>
> std.meta was moved from std.typetuple, and it now publicly imports std.meta.
>
> -Steve

It is possible for std.typetuple to publicly import std.meta and have the alias also in there?

On 6/24/15 12:29 PM, Steven Schveighoffer wrote:

> 1. Any code that was written to use the string version is currently
> passing a string for the extension. Only provide a cached conversion to
> string if that is the case (i.e. you have 2 strings passed in), and
> we'll be fine for existing code. Store the cached string into one of the
> two stored ranges. Don't even bother allowing conversion from non-string
> ranges to a string, just don't compile. This solves the space problem.
>
> 2. Code that is using the string version can call array, or can
> specifically say "string x = ..." instead of "auto x = ..." to avoid
> extra checks if they want to squeeze out that little test instruction. I
> don't see why we should care about an extra check for code that is
> deprecated or undesirable, and I don't see how the extra check is that
> bad either.
>
> I really like Adam's idea. A lot.

So I actually implemented this. I made it a std.internal type so it can be used wherever you need to port string concatenation to a chain.

A curious thing though. All the tests for things like:

assert(setExtension("file", "ext") == "file.ext");

do not trigger a call to eager. But this does:

assert(setExtension("file", "ext").array == "file.ext");

This might be a deal breaker, or alternative, I have no clue what's going on here...

The branch is pushed, but I don't know if it's in PR form, especially considering the above. See if it makes sense to everyone, and it's probably got some bugs :)

https://github.com/schveiguy/phobos/tree/setextfix

-Steve

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 love painting bike sheds!

An eager version implies present tense: split, join etc

A lazy version implies future tense: willSplit, willJoin, etc