www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New names - 2.068 roundup

reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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?
Jun 23 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
Jun 23 2015
next sibling parent reply "Mike" <none none.com> writes:
`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
Jun 23 2015
parent "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 23 June 2015 at 23:13:11 UTC, Mike wrote:

 `setExtensionLazy`

 Mike


I really don't like the Lazy suffix. Ignoring the issue of making 
things somewhat uglier solely for the purpose of ambiguity, it 
also leads to confusion regarding whether you should be invoking 
foo or fooLazy. Is there a fooLazy for this, or is it just foo, 
and why? Just because it was implemented before some arbitrary 
point? The lazy approach should be strongly preferred and should 
be the default; if the user wants the non-lazy version, they can 
use .array. Plus, as mentioned, people will start thinking that 
their own code should use this Lazy suffix which is likely 
something we don't want to encourage.

The current setExt name has the same issues I mentioned above, 
and it honestly is very odd to me to see setExt as well as 
setExtension if we're not intending to slowly phase out 
setExtension. The proposed withExtension indicates that it takes 
in a range and returns a range with the modifications applied, 
and I quite like it. I think that should be a trend for lazy 
algorithms, or at least a way to disambiguate.
Jun 23 2015
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 23 2015
prev sibling next sibling parent Yazan D <invalid email.com> writes:
On Tue, 23 Jun 2015 22:51:06 +0000, Vladimir Panteleev wrote:


 Proposed new name: withExtension


+1
Jun 24 2015
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 23 June 2015 at 22:51:08 UTC, Vladimir Panteleev 
wrote:

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

 Proposed new name: withExtension


I feel this fails the litmus you established before: "These 
functions have the same functionality, but one of them is eager, 
and the other is lazy. Can you guess which is which?"

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.

-Wyatt
Jun 24 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 24 June 2015 at 14:01:32 UTC, Wyatt wrote:

 On Tuesday, 23 June 2015 at 22:51:08 UTC, Vladimir Panteleev 
 wrote:

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

 Proposed new name: withExtension


 I feel this fails the litmus you established before: "These 
 functions have the same functionality, but one of them is 
 eager, and the other is lazy. Can you guess which is which?"

 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?
Jun 24 2015
parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Jun 24 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
Jun 23 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
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 

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
Jun 23 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
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 

 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.
Jun 23 2015
parent Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Jun 23 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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 

 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?


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?
Jun 23 2015
next sibling parent Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, Jun 23, 2015 at 4:49 PM, Vladimir Panteleev via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 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 /

 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?


 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?


+1

If I'd seen this two minutes ago could have saved me some typing.
Jun 23 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev 
wrote:

 - 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.


Another point: the range-ification of Phobos is only going to 
continue. This means that, should this scheme be followed, the 
number of functions with "Lazy" in the same is only going to 
grow, and as these functions are intended to become the canonical 
way to write modern D, so will the number of occurrences of 
"Lazy" in a typical canonical D program. I think this is a strong 
argument for avoiding "Lazy", at least for functions which intend 
to displace their eager counterparts.
Jun 23 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev 
wrote:

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

 - 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.


 Another point: the range-ification of Phobos is only going to 
 continue. This means that, should this scheme be followed, the 
 number of functions with "Lazy" in the same is only going to 
 grow, and as these functions are intended to become the 
 canonical way to write modern D, so will the number of 
 occurrences of "Lazy" in a typical canonical D program. I think 
 this is a strong argument for avoiding "Lazy", at least for 
 functions which intend to displace their eager counterparts.


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.
Jun 23 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 June 2015 at 00:16:49 UTC, Tofu Ninja wrote:

 On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev 
 wrote:

 Another point: the range-ification of Phobos is only going to 
 continue. This means that, should this scheme be followed, the 
 number of functions with "Lazy" in the same is only going to 
 grow, and as these functions are intended to become the 
 canonical way to write modern D, so will the number of 
 occurrences of "Lazy" in a typical canonical D program. I 
 think this is a strong argument for avoiding "Lazy", at least 
 for functions which intend to displace their eager 
 counterparts.


 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.


Well, it's true, any chosen decision is going to be a compromise.

Appending "Lazy" is only easy because the work to come up with 
suitable names has already been done for the eager variants. 
Finding suitable names for the lazy variants would entail doing 
similar work, perhaps with a bit more effort to communicate that 
this version is not eager.

I'll collect some data tomorrow to see if it's possible to find a 
likeable convention for lazy function names. But even if this 
will fail and we'll have to settle for inconsistency, I think 
overall the situation will still be better than having "Lazy" 
sprinkled everywhere. It will also be consistent with the names 
so far (e.g. join/joiner) :)
Jun 23 2015
parent Jacob Carlborg <doob me.com> writes:
On 24/06/15 03:05, Vladimir Panteleev wrote:


 Well, it's true, any chosen decision is going to be a compromise.

 Appending "Lazy" is only easy because the work to come up with suitable
 names has already been done for the eager variants. Finding suitable
 names for the lazy variants would entail doing similar work, perhaps
 with a bit more effort to communicate that this version is not eager.


It's hard enough to come up with one good name, it will be even harder 
to come up with a second name. Trying to come up with names indicating 
one is eager and one is lazy will be almost impossible.


 I'll collect some data tomorrow to see if it's possible to find a
 likeable convention for lazy function names. But even if this will fail
 and we'll have to settle for inconsistency, I think overall the
 situation will still be better than having "Lazy" sprinkled everywhere.
 It will also be consistent with the names so far (e.g. join/joiner) :)


join/joiner is almost as bad as setExtension/setExt.

-- 
/Jacob Carlborg
Jun 24 2015
prev sibling parent "ixid" <adamsibson hotmail.com> writes:
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
Jun 24 2015
prev sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 23 June 2015 at 23:58:52 UTC, Vladimir Panteleev 
wrote:

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

 - 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.


 Another point: the range-ification of Phobos is only going to 
 continue. This means that, should this scheme be followed, the 
 number of functions with "Lazy" in the same is only going to 
 grow, and as these functions are intended to become the 
 canonical way to write modern D, so will the number of 
 occurrences of "Lazy" in a typical canonical D program. I think 
 this is a strong argument for avoiding "Lazy", at least for 
 functions which intend to displace their eager counterparts.


Ok, I'm with you.  Allow me to offer another suggestion then.

1. Add functions `toUpperCaseEager` and `toLowerCaseEager`.
2. Have `toUpper` forward to `toUpperCaseEager` and `toLower` 
forward to `toLowerCaseEager` with a friendly comment.  You don't 
need to deprecate `toUpper` or `toLower` unless you want to.  It 
will happen naturally and gradually in time anyway.
3. Add functions `toUpperCase` and `toLowerCase` implementing the 
lazy versions.

Something similar could also be applied to `setExtension`
1. Add `setExt` implementing the lazy version and `setExtEager` 
implementing the eager version
2. Forward `setExtension` to `setExtEager` with a friendly 
comment.  Again, you don't need to deprecate `setExtension` 
unless you want to.  It will happen naturally and gradually in 
time anyway.

If this only makes things worse in your opinion, go with 
`withExtension` and your other suggestions.  I'm already weary of 
this.

Mike
Jun 23 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 24/06/15 02:17, Mike wrote:


 Ok, I'm with you.  Allow me to offer another suggestion then.

 1. Add functions `toUpperCaseEager` and `toLowerCaseEager`.
 2. Have `toUpper` forward to `toUpperCaseEager` and `toLower` forward to
 `toLowerCaseEager` with a friendly comment.  You don't need to deprecate
 `toUpper` or `toLower` unless you want to.  It will happen naturally and
 gradually in time anyway.
 3. Add functions `toUpperCase` and `toLowerCase` implementing the lazy
 versions.


How will that make things better? A user will see both toLower and 
toLowerCase can think: "What the h*ll is the difference between these to 
functions".

-- 
/Jacob Carlborg
Jun 24 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 24 June 2015 at 13:31:00 UTC, Jacob Carlborg wrote:

 How will that make things better? A user will see both toLower 
 and toLowerCase can think: "What the h*ll is the difference 
 between these to functions".


Absolutely.

I don't even like names that are just kinda similar. Ruby, for 
example, has `chop` and `chomp`. What's the difference? idk, I 
have to look it up. (chop will also remove non-newlines from the 
end)


At least toLower vs toLowerCase would have different types, so 
the compiler can help explain which is which, but really, ugh.


BTW here's another outside-the-box idea.

eager = toLower
lazy = map!lowercase


Yes, just provide a function that works on chars and reuse map 
for laziness.
Jun 24 2015
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 24 June 2015 at 13:43:50 UTC, Adam D. Ruppe wrote:

 Yes, just provide a function that works on chars and reuse map 
 for laziness.


Actually, this might not quite work because toLower/Upper might 
need to transform two characters at once in some alphabets. Ugh.

still I do generally like the idea of getting users used to 
composing building blocks themselves. We provide the pieces and 
the docs tell them how to put it together. If foo().bar() works, 
no need to always write a new foobar() function too.
Jun 24 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 24/06/15 15:43, Adam D. Ruppe wrote:


 Absolutely.

 I don't even like names that are just kinda similar. Ruby, for example,
 has `chop` and `chomp`. What's the difference? idk, I have to look it
 up. (chop will also remove non-newlines from the end)


Yeah, Ruby has one too many aliases:

filter/select, find/detect, map/collect and the best: size/length/count. 
Do you know the difference between size, length and count?

-- 
/Jacob Carlborg
Jun 24 2015
next sibling parent reply "Suliman" <evermind live.ru> writes:
On Wednesday, 24 June 2015 at 20:00:00 UTC, Jacob Carlborg wrote:

 On 24/06/15 15:43, Adam D. Ruppe wrote:


 Absolutely.

 I don't even like names that are just kinda similar. Ruby, for 
 example,
 has `chop` and `chomp`. What's the difference? idk, I have to 
 look it
 up. (chop will also remove non-newlines from the end)


 Yeah, Ruby has one too many aliases:

 filter/select, find/detect, map/collect and the best: 
 size/length/count. Do you know the difference between size, 
 length and count?


Adam, +1, I am always confusing when try to remember difference 
between chomp and chop.

If not to look at docs I would say that size is bite size, count 
- number of elements. So what is length I can't say. Probably I 
missed length and count.
Jun 24 2015
parent Jacob Carlborg <doob me.com> writes:
On 24/06/15 22:07, Suliman wrote:


 If not to look at docs I would say that size is bite size, count -
 number of elements. So what is length I can't say. Probably I missed
 length and count.


"length" and "size" are the exact same thing. They return the number of 
elements of an array or string. "count" is a bit more versatile, it can 
be called without parameters, with one parameter or with a block. If a 
parameter is given it will count the number of occurrences of that 
element. If a block is given it will pass each element to the block and 
count how many times it returns true. If no parameter or block is given 
it will work exactly like "length" and "size".

It gets event more interesting if you add ActiveRecord to the mix. The 
result of a query in ActiveRecord will return some form of object that 
acts like an array. Example:

Person.where(name: 'John').length

Will get all rows matching "John" and return how many. This on the other 
hand:

Person.where(name: 'John').count

Will actually perform a count query, avoid loading all objects in memory.

-- 
/Jacob Carlborg
Jun 25 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/24/15 3:59 PM, Jacob Carlborg wrote:

 On 24/06/15 15:43, Adam D. Ruppe wrote:


 Absolutely.

 I don't even like names that are just kinda similar. Ruby, for example,
 has `chop` and `chomp`. What's the difference? idk, I have to look it
 up. (chop will also remove non-newlines from the end)


 Yeah, Ruby has one too many aliases:

 filter/select, find/detect, map/collect and the best: size/length/count.
 Do you know the difference between size, length and count?


I recently started learning ruby. Going through a tutorial, I came 
across this gem (no pun intended) when talking about how both intern and 
to_sym do the same thing:

"Why have multiple ways to do the same things?

Well, that's a silly question. To be able to write expressive code. A 
language that only has one way to get from A to B is not a language at all."

Wow.

-Steve

http://www.codecademy.com/forum_questions/512a675cf116c52d0d00674b
Jun 24 2015
parent Jacob Carlborg <doob me.com> writes:
On 24/06/15 22:56, Steven Schveighoffer wrote:


 I recently started learning ruby. Going through a tutorial, I came
 across this gem (no pun intended) when talking about how both intern and
 to_sym do the same thing:


Hmm, I didn't know about "intern". I've never seen in the wild.


 "Why have multiple ways to do the same things?

 Well, that's a silly question. To be able to write expressive code. A
 language that only has one way to get from A to B is not a language at
 all."

 Wow.


Hehe :)

-- 
/Jacob Carlborg
Jun 25 2015
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev 
wrote:

 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 

 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".


And hopefully not many would have to. I can't say that this is 
the right solution for all lazy / range-based code going forward, 
but it's better than what we have, and I believe it's better than 
withExtension / upperCased / etc.


 - 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?


They would definitely be more recognizable as lazy functions, at 
the least. This would make code using std.algorithm more verbose, 
but we're not looking at changing every name in std.algorithm. 
We're looking at changing a couple of very bad names that give no 
indication that they're lazy / range-based (and let's not forget 
that the two aren't synonymous; we do have a lazy keyword after 
all).



 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?


It is a bit longer, but 4 extra characters is not all that much 
to pay to make a few functions much clearer about what they do.
Jun 23 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 23 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 23 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 24/06/15 01:17, 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

 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


+1

-- 
/Jacob Carlborg
Jun 24 2015
prev sibling next sibling parent "Mike" <none none.com> writes:
`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
Jun 23 2015
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 23 2015
next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Jun 24 2015
parent Jacob Carlborg <doob me.com> writes:
On 24/06/15 09:03, Tofu Ninja wrote:


 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.


I don't like that. There's a method in Ruby on Rails that's called 
"capitalize". It converts the first letter to a capital and the 
remaining ones to lower case.

-- 
/Jacob Carlborg
Jun 24 2015
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 June 2015 at 05:20:38 UTC, Jonathan M Davis 
wrote:

 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 think splitter and joiner are the exception rather than the 
rule, actually:

http://wiki.dlang.org/Naming_conventions

Most of the hypothetical names in that column (verb-noun) are 
pretty ugly. I don't think this is a convention we should adopt.

The problem with toXCase is that there is neither a noun for an 
upper-case transform, nor a verb for such an operation, such as 
e.g. "capitalization" and "capitalize", so I think we should look 
at it separately.

I think someone suggested lowerCased and upperCased somewhere, I 
think there are fine too. There is some precedent (transposed and 
indexed).
Jun 24 2015
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 June 2015 at 13:35:06 UTC, Vladimir Panteleev 
wrote:

 I think someone suggested lowerCased and upperCased somewhere, 
 I think there are fine too. There is some precedent (transposed 
 and indexed).


Err, that someone was me. I thought my initial suggestion was 
asLowerCase / asUpperCase.
Jun 24 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 June 2015 at 13:35:06 UTC, Vladimir Panteleev 
wrote:

 The problem with toXCase is that there is neither a noun for an 
 upper-case transform, nor a verb for such an operation, such as 
 e.g. "capitalization" and "capitalize", so I think we should 
 look at it separately.


Well, I suppose simply "upperCase" and "lowerCase" are an 
options, if you squint your eyes and pretend they're verbs.
Jun 24 2015
next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Jun 24 2015
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 24 June 2015 at 20:03:35 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 24 June 2015 at 13:35:06 UTC, Vladimir Panteleev 
 wrote:

 The problem with toXCase is that there is neither a noun for 
 an upper-case transform, nor a verb for such an operation, 
 such as e.g. "capitalization" and "capitalize", so I think we 
 should look at it separately.


 Well, I suppose simply "upperCase" and "lowerCase" are an 
 options, if you squint your eyes and pretend they're verbs.


Of course, even if you consider these acceptable on their own, 
they don't really solve the problem of being memorably 
distinguishable from toLower / toUpper.
Jun 25 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 24/06/15 07:20, Jonathan M Davis wrote:


 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).


How is that consistent? The original names are toLower/toUpper, not 
lowerCase/upperCase. So it should be something like toLowerer but that 
clearly doesn't work.

-- 
/Jacob Carlborg
Jun 24 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 24 June 2015 at 13:37:35 UTC, Jacob Carlborg wrote:

 On 24/06/15 07:20, Jonathan M Davis wrote:


 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).


 How is that consistent? The original names are toLower/toUpper, 
 not lowerCase/upperCase. So it should be something like 
 toLowerer but that clearly doesn't work.


It's consistent with the naming scheme used by functions like 
splitter, joiner, or filter (though in filter's case, it's both a 
verb and a noun). The function is named after the noun that does 
the operation rather than the operation - e.g. the verb is split, 
but the one that does the splitting is the splitter. So, in the 
case of toLower and toUpper, what you're manipulating is the 
case, so following that naming scheme, a lower caser would be 
what did the to lower case operation, and an upper caser would be 
what did the to upper case operation. Now, that's ugly since 
caser isn't a real word (there really isn't a noun for something 
which changes a letter to uppercase or lowercase), but it's 
following the same scheme as splitter. Conversely, we could go 
with lowerer and upperer, though those are pretty ugly and 
nonsensical too, but having to in the name doesn't follow the 
convention that we use with functions like splitter or joiner, so 
toLowerer like you suggest wouldn't fit.

All in all, because there is no noun or object which changes the 
case of letters (it's really just an operation), following the 
naming scheme of functions like splitter is bound to be ugly. But 
it _is_ making them consistent with what we've done with the 
names of existing functions when we've made lazy versions of them 
(e.g. split -> splitter, and join -> joiner).

- Jonathan M Davis
Jun 24 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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? :)
Jun 25 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 25 2015
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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".
Jun 25 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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"))
Jun 25 2015
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 25 2015
prev sibling next sibling parent David Gileadi <gileadis NSPMgmail.com> writes:
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.
Jun 25 2015
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2015 04:10 PM, 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"))


Definitely. The existing functions should have been named 'joined' and 
'splitted'. :o)
Jun 25 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 25 June 2015 at 20:41:13 UTC, Timon Gehr wrote:

 On 06/25/2015 04:10 PM, 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"))


 Definitely. The existing functions should have been named 
 'joined' and 'splitted'. :o)


I actually hypothesize that "joiner"/"splitter" were chosen 
because "split" the verb's past tense is also "split", which was 
taken by the eager function.
Jun 25 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2015 10:42 PM, Vladimir Panteleev wrote:

 On Thursday, 25 June 2015 at 20:41:13 UTC, Timon Gehr wrote:

 On 06/25/2015 04:10 PM, 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"))


 Definitely. The existing functions should have been named 'joined' and
 'splitted'. :o)


 I actually hypothesize that "joiner"/"splitter" were chosen because
 "split" the verb's past tense is also "split", which was taken by the
 eager function.


It was intended as a joke, but apparently the word exists/existed 
https://en.wiktionary.org/wiki/splitted .
Jun 25 2015
prev sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev 
wrote:

 So, one option is to stay consistent with these additions, and 
 go with upperCaser and lowerCaser, even if those sound a bit 
 odd.


Why not upperCaseSetter/lowerCaseSetter? Bit longer but upper 
case and lower case don't have a good noun version. Personally 
upperCaser/lowerCaser sound really bad to me, though I like the 
idea of keeping it a noun because that matches every thing else.
Jun 25 2015
parent Mike Parker <aldacron gmail.com> writes:
On 6/26/2015 5:04 AM, Tofu Ninja wrote:

 On Thursday, 25 June 2015 at 13:04:12 UTC, Vladimir Panteleev wrote:

 So, one option is to stay consistent with these additions, and go with
 upperCaser and lowerCaser, even if those sound a bit odd.


 Why not upperCaseSetter/lowerCaseSetter? Bit longer but upper case and
 lower case don't have a good noun version. Personally
 upperCaser/lowerCaser sound really bad to me, though I like the idea of
 keeping it a noun because that matches every thing else.


I think upperCaser and lowerCaser are just fine. And I'm saying that as 
someone who has been teaching English in Korea for a couple of decades 
:) No, these aren't words we would normally use. But a couple of points.

1. An -er suffix is immediately recognizable in most cases as "a thing 
that takes an action." Native English-speaking children and, in my 
experience, non-native speakers often tack it on to verbs to create a 
"doer" noun even when a different word already exists. A great example 
is "cooker" to refer to a "cook". It's well-understood from that 
perspective.

2. English is full of broken conventions, making it more onerous to 
learn vocabulary than it ought to be. I think we should pick an 
easily-understood convention that fits the usage of whatever category of 
functions we're dealing with and stick with it as zealously as possible, 
even if it means using words that aren't part of the language or that 
don't look so pretty when they are strung together. Doing so makes it 
much easier to reason at a glance about what's going on.

upperCased/lowerCased work fine for strings that have already been 
transformed, but ranges that carry out the transformation are more 
accurately named upperCaser/lowerCaser. IMO, that's the simplest, most 
self-descriptive name these functions could have.
Jun 25 2015
prev sibling next sibling parent Yazan D <invalid email.com> writes:
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
Jun 24 2015
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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


Havent't read the entire thread yet, but in case it hasn't been 
suggested yet:

inLowerCase / inUpperCase
Jun 24 2015
prev sibling parent reply "Andrew Gough" <andrew goughy.org> writes:
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
Jun 24 2015
parent "Andrew Gough" <andrew goughy.org> writes:
On Thursday, 25 June 2015 at 03:15:58 UTC, Andrew Gough 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 love painting bike sheds!

 An eager version implies present tense: split, join etc

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


And hence: willUpperCase, willLowerCase
Jun 24 2015
prev sibling next sibling parent reply "Mike" <none none.com> writes:
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
Jun 23 2015
parent reply Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, Jun 23, 2015 at 4:33 PM, Mike via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 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.


This would make it a convention.  And a poor one, as it basically says 'do
your own thing, but if you do something confusing stick lazy on the end.'
 Better in my opinion to have a convention that covers things in the first
place, so you never get to the point where differentiating via 'lazy' seems
like a good idea.


I actually don't think having separate threads for each name is the best
solution.  May be better to get them all listed in one place, and see if a
consistent naming system can emerge.



 Jun 23 2015



  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Tuesday, 23 June 2015 at 23:58:07 UTC, Jeremy Powers wrote:

 I actually don't think having separate threads for each name is 
 the best solution.  May be better to get them all listed in one 
 place, and see if a consistent naming system can emerge.


I looked through std.range and std.algorithm and created this 
page:

http://wiki.dlang.org/Naming_conventions



 Jun 24 2015



  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Wednesday, 24 June 2015 at 13:27:17 UTC, Vladimir Panteleev 
wrote:

 On Tuesday, 23 June 2015 at 23:58:07 UTC, Jeremy Powers wrote:

 I actually don't think having separate threads for each name 
 is the best solution.  May be better to get them all listed in 
 one place, and see if a consistent naming system can emerge.


 I looked through std.range and std.algorithm and created this 
 page:

 http://wiki.dlang.org/Naming_conventions


BTW, as for eager/mutating functions, they are almost all verbs:

== std.algorithm ==
sort
schwartzSort
largestPartialIntersection
bringToFront
copy
fill
moveAll
moveSome
remove

== std.array ==
join
replace
split
replicate



 Jun 24 2015



  parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Wednesday, 24 June 2015 at 13:40:28 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 24 June 2015 at 13:27:17 UTC, Vladimir Panteleev 
 wrote:

 On Tuesday, 23 June 2015 at 23:58:07 UTC, Jeremy Powers wrote:

 I actually don't think having separate threads for each name 
 is the best solution.  May be better to get them all listed 
 in one place, and see if a consistent naming system can 
 emerge.


 I looked through std.range and std.algorithm and created this 
 page:

 http://wiki.dlang.org/Naming_conventions


 BTW, as for eager/mutating functions, they are almost all verbs:

 == std.algorithm ==
 sort
 schwartzSort
 largestPartialIntersection
 bringToFront
 copy
 fill
 moveAll
 moveSome
 remove

 == std.array ==
 join
 replace
 split
 replicate


Which is sensible. A range is an object that performs an action, 
an eager function is the action itself.



 Jun 24 2015



  parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Wednesday, 24 June 2015 at 13:45:27 UTC, John Colvin wrote:

 On Wednesday, 24 June 2015 at 13:40:28 UTC, Vladimir Panteleev 
 wrote:

 BTW, as for eager/mutating functions, they are almost all 
 verbs:

 [...]


 Which is sensible. A range is an object that performs an 
 action, an eager function is the action itself.


Yep, just another data point.



 Jun 24 2015



prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


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:

---

import std.range;

struct ToLowered(R) if(isInputRange!R) {
	R inputRange;
	this(R r) {
		static if(isForwardRange!R)
			inputRange = r;
		if(!empty)
			front = cast(char) (inputRange.front | 0x20);
	}

	char front;

	static if(isForwardRange!R)
	typeof(this) save() { return this; }

	bool empty() {
		return inputRange.empty();
	}

	void popFront() {
		inputRange.popFront();
		if(!empty)
			front = cast(char) (inputRange.front | 0x20);
	}

	private immutable(char)[] eagerCache;
	deprecated("please call .array on this yourself or adjust your 
algorithm to use the laziness (tip: changing string declarations 
to auto may help)")
	string eager() pure {
		if(eagerCache is null) {
			foreach(c; this)
				eagerCache ~= c;
		}
		return eagerCache;
	}

  	alias eager this;
}

ToLowered!R toLower(R)(R r) {
	return ToLowered!R(r);
}


void main() {
	import std.stdio;

	string s = "Amazing Stuff".toLower; // alias this!
	writeln(s);

	string[string] lol;
	lol["FOO"] = "FOO".toLower; // alias this!

	writeln(lol);
}

---


The code breakage is minimal (especially if we don't actually 
deprecate that eager method) - cases where a string is expected 
is automatically handled by the alias this, and pipelines using 
auto will just work. Copying this struct has the same semantics 
as copying the string The change of type can break code - but 
only code that was neither quite static nor quite generic.

Code that statically takes a string works, as will returning a 
string, that's also covered by alias this. Code that generically 
works on input/forward ranges works, as this is still a by-value 
forward range. Only code that takes a template argument and 
literally checks if(is(T == string)) or if(is(isArray!T)) and 
those variants will break on this.



I confess, that is some code, but with alias this, we have a 
migration path to change a lot of usages of the existing 
functions to be lazy without dreaming up new names.

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!



 Jun 23 2015



 next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


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



 Jun 23 2015



  parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


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



 Jun 23 2015



prev sibling next sibling parent  "Adrian Matoga" <epi atari8.info>  writes:


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!


+1



 Jun 24 2015



prev sibling next sibling parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


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:

 ---

 import std.range;

 struct ToLowered(R) if(isInputRange!R) {
 	R inputRange;
 	this(R r) {
 		static if(isForwardRange!R)
 			inputRange = r;
 		if(!empty)
 			front = cast(char) (inputRange.front | 0x20);
 	}

 	char front;

 	static if(isForwardRange!R)
 	typeof(this) save() { return this; }

 	bool empty() {
 		return inputRange.empty();
 	}

 	void popFront() {
 		inputRange.popFront();
 		if(!empty)
 			front = cast(char) (inputRange.front | 0x20);
 	}

 	private immutable(char)[] eagerCache;
 	deprecated("please call .array on this yourself or adjust your 
 algorithm to use the laziness (tip: changing string 
 declarations to auto may help)")
 	string eager() pure {
 		if(eagerCache is null) {
 			foreach(c; this)
 				eagerCache ~= c;
 		}
 		return eagerCache;
 	}

  	alias eager this;
 }

 ToLowered!R toLower(R)(R r) {
 	return ToLowered!R(r);
 }


 void main() {
 	import std.stdio;

 	string s = "Amazing Stuff".toLower; // alias this!
 	writeln(s);

 	string[string] lol;
 	lol["FOO"] = "FOO".toLower; // alias this!

 	writeln(lol);
 }

 ---


 The code breakage is minimal (especially if we don't actually 
 deprecate that eager method) - cases where a string is expected 
 is automatically handled by the alias this, and pipelines using 
 auto will just work. Copying this struct has the same semantics 
 as copying the string The change of type can break code - but 
 only code that was neither quite static nor quite generic.

 Code that statically takes a string works, as will returning a 
 string, that's also covered by alias this. Code that 
 generically works on input/forward ranges works, as this is 
 still a by-value forward range. Only code that takes a template 
 argument and literally checks if(is(T == string)) or 
 if(is(isArray!T)) and those variants will break on this.



 I confess, that is some code, but with alias this, we have a 
 migration path to change a lot of usages of the existing 
 functions to be lazy without dreaming up new names.

 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!


Yup, mind completely blown.

I almost want to put "alias eager this;" in all my ranges now...



 Jun 24 2015



prev sibling next sibling parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 24-Jun-2015 04:03, 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:


[snip]

 I confess, that is some code, but with alias this, we have a migration
 path to change a lot of usages of the existing functions to be lazy
 without dreaming up new names.

 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!


+1
Feels dangerously seductive.

-- 
Dmitry Olshansky



 Jun 24 2015



prev sibling next sibling parent reply "John Chapman" <johnch_atms hotmail.com>  writes:


On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:

 The code breakage is minimal


Won't this break isSomeString? Phobos uses this everywhere.



 Jun 24 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 24 June 2015 at 11:12:27 UTC, John Chapman wrote:

 On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:

 The code breakage is minimal


 Won't this break isSomeString? Phobos uses this everywhere.


It won't break isSomeString. isSomeString will continue to work 
the same. What it will mean is that the result of toLower won't 
pass isSomeString anymore, and if you pass it to a range-based 
function which has an overload for strings, it won't match it and 
will be treated the same as a range like FilterResult and not get 
the string optimizations. If you want it to actually be a string, 
then you'll need to use to!string on it (even std.array.array 
wouldn't work, since that would convert it to dchar[], not 
string).

So, that could be a reason why this isn't a great idea, but it 
once again highlights why having autodecoding is a bad idea, and 
it shows that as we increase how much we're doing with functions 
which return lazy ranges, the cost of having autodecoding will 
only increase, because we'll being dealing with strings directly 
less and less.

- Jonathan M Davis



 Jun 24 2015



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 24/06/15 13:28, Jonathan M Davis wrote:


 It won't break isSomeString. isSomeString will continue to work the
 same. What it will mean is that the result of toLower won't pass
 isSomeString anymore, and if you pass it to a range-based function which
 has an overload for strings, it won't match it and will be treated the
 same as a range like FilterResult and not get the string optimizations.
 If you want it to actually be a string, then you'll need to use
 to!string on it (even std.array.array wouldn't work, since that would
 convert it to dchar[], not string).

 So, that could be a reason why this isn't a great idea, but it once
 again highlights why having autodecoding is a bad idea, and it shows
 that as we increase how much we're doing with functions which return
 lazy ranges, the cost of having autodecoding will only increase, because
 we'll being dealing with strings directly less and less.


Can't we update isSomeString to detect this use case?

-- 
/Jacob Carlborg



 Jun 24 2015



  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Wednesday, 24 June 2015 at 13:43:04 UTC, Jacob Carlborg wrote:

 Can't we update isSomeString to detect this use case?


We _could_ but that would be a disaster. The whole point of 
isSomeString is to test whether something is a string exactly. 
The code used by a function that's overloaded specifically on 
strings needs to operate on strings. If isSomeString suddenly 
accepted something which implicitly converted to a string rather 
than a string, then most functions which used isSomeString in 
their template constraints, would fail to compile when used with 
such a range. In general, implicit conversions in template 
constraints are incredibly dangerous - especially when alias this 
is involved - because unless the conversion is actually done, the 
type in question won't act exactly as whatever it converts to, 
and when given something that implicitly converts, it will either 
not compile, or it will have incorrect behavior.

A while back, it was temporarily changed so that isSomeString, 
isIntegeral, etc. accepted implicit conversions, but that was 
reverted fairly quickly, precisely because it's so dangerous. 
Templated functions should only be dealing with implicit 
conversions when they force the conversion.

We could choose to write overloads for Phobos functions which 
accepted ranges that implicitly converted to string, explicitly 
convert them to string, and then call the string overload, but 
then they'd always allocate, whereas maybe the overload which 
operated on non-strings would have been better, because it 
wouldn't have required any allocation. So really, what we need is 
to either change is that strings are ranges of their code unit 
type rather than dchar, or we need to be using byCodeUnit and 
friends a lot more. I believe that Walter has been trying to do 
that with the lazy versions of functions, but any of them which 
result in ranges of dchar are going to no longer be strings, and 
even those that use byCodeUnit won't be able to take advantage of 
overloads for strings or arrays anymore, because they won't be 
strings.

Part of what we need to do is go through Phobos and make it so 
that the various range-based functions which operate on strings 
operate on ranges of char just as well, then byCodeUnit and its 
ilk can be optimized appropriately. But they're not going to work 
with the current overloads which take strings, because they are 
neither arrays nor strings.

- Jonathan M Davis



 Jun 24 2015



prev sibling  parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Wed, Jun 24, 2015 at 11:28:46AM +0000, Jonathan M Davis via Digitalmars-d
wrote:

 On Wednesday, 24 June 2015 at 11:12:27 UTC, John Chapman wrote:

On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote:

The code breakage is minimal


Won't this break isSomeString? Phobos uses this everywhere.


 
 It won't break isSomeString. isSomeString will continue to work the
 same.  What it will mean is that the result of toLower won't pass
 isSomeString anymore, and if you pass it to a range-based function
 which has an overload for strings, it won't match it and will be
 treated the same as a range like FilterResult and not get the string
 optimizations. If you want it to actually be a string, then you'll
 need to use to!string on it (even std.array.array wouldn't work, since
 that would convert it to dchar[], not string).
 
 So, that could be a reason why this isn't a great idea, but it once
 again highlights why having autodecoding is a bad idea, and it shows
 that as we increase how much we're doing with functions which return
 lazy ranges, the cost of having autodecoding will only increase,
 because we'll being dealing with strings directly less and less.


[...]

Yet another nail in the coffin of autodecoding. I really wish we had
toughed it out earlier and begun phasing it out. It's kinda late for
that now... but maybe it might still be worth it?


T

-- 
I am Ohm of Borg. Resistance is voltage over current.



 Jun 24 2015



 next sibling parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Wednesday, 24 June 2015 at 15:40:54 UTC, H. S. Teoh wrote:

 Yet another nail in the coffin of autodecoding. I really wish 
 we had toughed it out earlier and begun phasing it out. It's 
 kinda late for that now... but maybe it might still be worth it?


As I understand, Andrei's opinion still is that auto-decoding was 
the better choice, so I think that's extremely unlikely to happen.



 Jun 24 2015



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 6/24/15 8:37 AM, H. S. Teoh via Digitalmars-d wrote:

 Yet another nail in the coffin of autodecoding. I really wish we had
 toughed it out earlier and begun phasing it out. It's kinda late for
 that now... but maybe it might still be worth it?


Autodecoding is here to stay. -- Andrei



 Jun 24 2015



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 24/06/15 03:03, 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 like it :) But I fear it will break code and Walter won't like that.

-- 
/Jacob Carlborg



 Jun 24 2015



prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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:

 [...]


Some thoughts:

- I think the implementation is better done through composition 
(i.e. a function that takes any range, and returns a type that 
works like that range but also allows implicit conversion to 
string. Not sure how feasible this is, maybe multiple alias this 
will help.

- On the performance side, one point is that this grows the size 
of the struct by two machine words (string's .ptr and .length). 
This type is likely to be passed by value through function 
parameters, too.

- Another perf. issue is that this introduces additional cost 
every time the implicit conversion to string is done (you need to 
at least check if the string value has been calculated).

Ultimately I think it's interesting but I defer the final answer 
to Walter/Andrei, and I think I can predict their answer.



 Jun 24 2015



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 24 June 2015 at 13:50:09 UTC, Vladimir Panteleev 
wrote:

 - I think the implementation is better done through composition


Perhaps, though I was thinking of this as being just a temporary 
step for migration until it is deprecated - it helps a lot of 
code continue to just work, but at the cost of a silent 
allocation which we would want to avoid.

If it needed composition on the usage point, it'd defeat the 
point of minimizing code breakage.


 - On the performance side, one point is that this grows the 
 size of the struct by two machine words (string's .ptr and 
 .length). This type is likely to be passed by value through 
 function parameters, too.


Aye, that's a compromise again - it could just allocate a new 
string in that eager method, but since it is implicit, that could 
easily waste a lot more time than the extra cached string.

Ideally though, a year from now, that'd be deprecated and removed 
in favor of having the user migrate to explicit allocation on 
their end, becoming fully lazy. (That's what I really want to do: 
make phobos all lazy and make the allocation a user-level 
decision, I'm just trying to offer something that has a less 
breakage migration path.)



So my plan is:

1) Change to lazy with the implicit conversion in a 
version(future_phobos) else {} block. Tell everyone this 
conversion sucks and they want to get away from it. Use 
-version=future_phobos to see what code is likely to break when 
they recompile so they can start handling it.

2) Next release, put deprecated("use .array or lazy instead") (or 
maybe not .array as it can yield dchar when you want char, but 
whatever actually works right) on that method.

3) A year later, move this code into a version(D_067_compatible) 
block so the old eager behavior is now opt-in. So now, the 
default build no longer has the alias this, eager method, nor the 
string cache member.

4) Eventually, kill that version too to clean up the code.



That should be a reasonable migration path, with minimal code 
breakage, ample warning, and a really easy fix that the compiler 
tells you about to update your code.



 Jun 24 2015



 next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Wednesday, 24 June 2015 at 14:29:34 UTC, Adam D. Ruppe wrote:

 If it needed composition on the usage point, it'd defeat the 
 point of minimizing code breakage.


Not at the call site, but in the function (i.e. the function 
defines a voldemort struct, constructs one, wraps that into the 
helper that adds implicit string conversion, and returns that).


 Ideally though, a year from now, that'd be deprecated and 
 removed in favor of having the user migrate to explicit 
 allocation on their end, becoming fully lazy.


As I understand, we're not doing that any more.



 Jun 24 2015



 next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 24 June 2015 at 14:31:42 UTC, Vladimir Panteleev 
wrote:

 Not at the call site, but in the function (i.e. the function 
 defines a voldemort struct, constructs one, wraps that into the 
 helper that adds implicit string conversion, and returns that).


Oh yeah, we could do that.



 Jun 24 2015



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 6/24/15 7:31 AM, Vladimir Panteleev wrote:

 On Wednesday, 24 June 2015 at 14:29:34 UTC, Adam D. Ruppe wrote:

 If it needed composition on the usage point, it'd defeat the point of
 minimizing code breakage.


 Not at the call site, but in the function (i.e. the function defines a
 voldemort struct, constructs one, wraps that into the helper that adds
 implicit string conversion, and returns that).


 Ideally though, a year from now, that'd be deprecated and removed in
 favor of having the user migrate to explicit allocation on their end,
 becoming fully lazy.


 As I understand, we're not doing that any more.


That is correct. -- Andrei



 Jun 24 2015



prev sibling next sibling parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Wednesday, 24 June 2015 at 14:29:34 UTC, Adam D. Ruppe wrote:

 On Wednesday, 24 June 2015 at 13:50:09 UTC, Vladimir Panteleev

 - On the performance side, one point is that this grows the 
 size of the struct by two machine words (string's .ptr and 
 .length). This type is likely to be passed by value through 
 function parameters, too.


 Aye, that's a compromise again - it could just allocate a new 
 string in that eager method, but since it is implicit, that 
 could easily waste a lot more time than the extra cached string.


This would be a great opportunity for automatic caching by the 
compiler. `eager` is pure, after all.



 Jun 24 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Please, no code breakage because of renaming.



 Jun 25 2015



  parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Thursday, 25 June 2015 at 20:54:38 UTC, Walter Bright wrote:

 Please, no code breakage because of renaming.


Well, the whole idea behind Adam's proposal to make functions 
like toLower return a struct which is a lazy range but uses alias 
this to do eager allocation is to allow us to switch to lazy by 
default with these functions without breaking code, because when 
you assigned it to a string, it would allocate just like it did 
before. So, in theory, there wouldn't be any code breakage.

However, as appealing as I find the idea of silently converting 
eager functions into lazy functions without breaking code, I'm 
not at all convinced that it will really work and that it won't 
break code. As long as the type string is used explicitly in the 
caller, it should be fine, but with enough uses of auto and 
interacting with other templated functions that do 
who-knows-what, I'm no sure that it's actually going to do the 
implicit conversion to string in all of the cases that it really 
needs to (e.g. the resulting range type would fail isSomeString, 
and if the function that you passed it to required isSomeString 
via its template constraint but didn't have an overload for 
generic ranges of dchar, it would fail to compile).

In general, implicit conversions are incredibly dangerous with 
generic code - particularly with regards to template constraints, 
because it's trivial to have a type which implicitly converts, 
but if the templated function doesn't actually force the 
conversion, then the function might not actually compile with the 
original type, and even if it does, you could get some weird, 
hybrid behavior where some of the operations in the function end 
up being done on the original type and some end up being done on 
the result of alias this. So, we need to be _very_ careful when 
using alias this in generic code.

So, while I do like Adam's idea in principle - and it shows off 
D's power nicely - I think that the fact that we're talking about 
combining alias this and generic code is a very risky 
proposition. It probably will work in _almost_ all cases without 
breaking any code, but I seriously question that it will work in 
_all_ cases.

- Jonathan M Davis



 Jun 25 2015



prev sibling  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 6/24/15 9:50 AM, Vladimir Panteleev 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:

 [...]


 Some thoughts:

 - I think the implementation is better done through composition (i.e. a
 function that takes any range, and returns a type that works like that
 range but also allows implicit conversion to string. Not sure how
 feasible this is, maybe multiple alias this will help.

 - On the performance side, one point is that this grows the size of the
 struct by two machine words (string's .ptr and .length). This type is
 likely to be passed by value through function parameters, too.

 - Another perf. issue is that this introduces additional cost every time
 the implicit conversion to string is done (you need to at least check if
 the string value has been calculated).


I think these points are not quite as bad as you think:

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.

-Steve



 Jun 24 2015



  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


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



 Jun 24 2015



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


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!)


 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. (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).

But since you did implement a length function, that shouldn't be 
happening. Maybe it passes the check in StringTypeOf though: is(T 
: const char[]) might pass due to the alias this too. Not sure.

(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.)



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.



 Jun 24 2015



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Thursday, 25 June 2015 at 03:40:31 UTC, 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.


That depends entirely on what the templated function that it's 
being used with does. In general, implicit conversions in generic 
code is an incredibly bad idea. Almost inevitably what happens is 
that folks assume that because the type is implicitly 
convertible, it can be treated like the type that it implicitly 
converts to - but that often isn't true at all. It just means 
that you can convert it to that type and then use it as that type 
rather than its original type. So, if a function checks for 
implicit conversion and then forces that conversion, then it can 
work, but it needs to force the conversion. Otherwise, it'll 
either fail to compile when used with types that use alias this, 
or you'll end up with weird, hybrid behavior where some of the 
operations might use the actual type, whereas others use the 
converted type. In general, I think that using implicit 
conversions in generic code is a disaster.

So, yes, if we use a struct like this, then in code which ends up 
assigning the result to a string (or passing it to a function 
which explicitly takes a string), then the implicit conversion 
will take place, and everything should work fine. However, in any 
code that assumes that it's dealing with strings but doesn't 
actually use the type string anywhere, it's not going to 
implicitly convert to string, and you could easily end up with 
templated functions which test with isSomeString or similar and 
thus fail to compile, because they wouldn't do the implicit 
conversion in that case (the duck typing sees that the struct 
_isn't_ a string). As long as the functions work with general 
ranges of dchar, they should be fine (possibly less performant if 
too much autodecoding is going on, but the lack of allocation may 
make up for that), but any generic code that assumes strings 
without specifically using the type string is in trouble. How 
much of a concern that really is, I don't know. But I would not 
expect much code that involves duck typing to be converting the 
struct to string, and in general, I would be very worried about 
any generic code that involved implicit conversions.

But this should work just fine when used with non-generic code 
that's operating on strings or with generic code that operates on 
ranges of dchar and not necessarily just strings.

- Jonathan M Davis



 Jun 24 2015



prev sibling next sibling parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


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



 Jun 25 2015



prev sibling  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


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



 Jun 25 2015



prev sibling  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


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

 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.


Seems like Andrei has nixed this idea:

"Please no breakages and no clever schemes and no overengineering."

http://forum.dlang.org/post/mmhjqe$2mud$1 digitalmars.com

Oh well. I'm kind of done with the whole naming thing, there are better 
things I could (and probably should) be doing. Plus arguing against 
Walter and/or Andrei is kind of an uphill battle, especially if they 
both agree on something.

I'll leave the branch up for anyone who wants to continue to try things 
with it, it was a very cool idea.

-Steve



 Jun 25 2015



  parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com>  writes:


2015-06-25 21:28 GMT+02:00 Steven Schveighoffer via Digitalmars-d <
digitalmars-d puremagic.com>:


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


 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.


 Seems like Andrei has nixed this idea:

 "Please no breakages and no clever schemes and no overengineering."

 http://forum.dlang.org/post/mmhjqe$2mud$1 digitalmars.com

 Oh well. I'm kind of done with the whole naming thing, there are better
 things I could (and probably should) be doing. Plus arguing against Walter
 and/or Andrei is kind of an uphill battle, especially if they both agree on
 something.

 I'll leave the branch up for anyone who wants to continue to try things
 with it, it was a very cool idea.

 -Steve


And he's right. It is really annoying to update to a new version and have
perfectly valid and working code breaking because someone had a nice idea.
Ideally, we should only ever break code that has a bug in it.



 Jun 25 2015



 next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 6/25/15 3:48 PM, Mathias Lang via Digitalmars-d wrote:

 2015-06-25 21:28 GMT+02:00 Steven Schveighoffer via Digitalmars-d
 <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>>:

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

         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.


     Seems like Andrei has nixed this idea:

     "Please no breakages and no clever schemes and no overengineering."

     http://forum.dlang.org/post/mmhjqe$2mud$1 digitalmars.com

     Oh well. I'm kind of done with the whole naming thing, there are
     better things I could (and probably should) be doing. Plus arguing
     against Walter and/or Andrei is kind of an uphill battle, especially
     if they both agree on something.

     I'll leave the branch up for anyone who wants to continue to try
     things with it, it was a very cool idea.


 And he's right. It is really annoying to update to a new version and
 have perfectly valid and working code breaking because someone had a
 nice idea. Ideally, we should only ever break code that has a bug in it.


Yeah, I agree for existing names, but these are unreleased new names.

-Steve



 Jun 25 2015



  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 25 June 2015 at 19:55:41 UTC, Steven Schveighoffer 
wrote:

 Yeah, I agree for existing names, but these are unreleased new 
 names.


I thought the idea was to use this trick to avoid introducing the 
new names, and instead change the established names in a 
mostly-backwards-compatible way.



 Jun 25 2015



 next sibling parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 6/25/15 3:57 PM, Vladimir Panteleev wrote:

 On Thursday, 25 June 2015 at 19:55:41 UTC, Steven Schveighoffer wrote:

 Yeah, I agree for existing names, but these are unreleased new names.


 I thought the idea was to use this trick to avoid introducing the new
 names, and instead change the established names in a
 mostly-backwards-compatible way.


Yeah, that is the idea. There should be no code breakage, or it won't 
fly. I took the "no clever schemes and no overengineering" as a 
rejection of this idea, only renaming is on the table.

-Steve



 Jun 25 2015



prev sibling  parent  Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 6/25/15 3:57 PM, Vladimir Panteleev wrote:

 On Thursday, 25 June 2015 at 19:55:41 UTC, Steven Schveighoffer wrote:

 Yeah, I agree for existing names, but these are unreleased new names.


 I thought the idea was to use this trick to avoid introducing the new
 names, and instead change the established names in a
 mostly-backwards-compatible way.


To be clearer, my change would remove the newly-added toExt. I don't 
consider this a breakage since it wasn't released. Instead, we would 
rewrite toExtension to do what toExt does, but in a backwards compatible 
way.

-Steve



 Jun 25 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 6/25/2015 12:48 PM, Mathias Lang via Digitalmars-d wrote:

 And he's right. It is really annoying to update to a new version and have
 perfectly valid and working code breaking because someone had a nice idea.
 Ideally, we should only ever break code that has a bug in it.


I've also been willing to break code if it involves significant performance, 
usability, or correctness improvements. Renaming, though, doesn't provide that.



 Jun 25 2015



 next sibling parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 25 June 2015 at 21:06:38 UTC, Walter Bright wrote:

 On 6/25/2015 12:48 PM, Mathias Lang via Digitalmars-d wrote:

 And he's right. It is really annoying to update to a new 
 version and have
 perfectly valid and working code breaking because someone had 
 a nice idea.
 Ideally, we should only ever break code that has a bug in it.


 I've also been willing to break code if it involves significant 
 performance, usability, or correctness improvements. Renaming, 
 though, doesn't provide that.


For the record, the goal of the breakage in this case is not 
renaming a function, but avoiding the need to introduce a 
newly-named alternative function in the first place.



 Jun 25 2015



prev sibling next sibling parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 06/25/2015 11:06 PM, Walter Bright wrote:

 On 6/25/2015 12:48 PM, Mathias Lang via Digitalmars-d wrote:

 And he's right. It is really annoying to update to a new version and have
 perfectly valid and working code breaking because someone had a nice
 idea.
 Ideally, we should only ever break code that has a bug in it.


 I've also been willing to break code if it involves significant
 performance, usability, or correctness improvements. Renaming, though,
 doesn't provide that.


It might support performance and usability, at least. Usability is 
obvious. For performance, just assume the eager version has a nicer, 
shorter or more memorable name than the lazy version. (which is the case 
now for e.g. join/joiner, split/splitter).

The main issue is that all those name-describing adjectives have no 
precise, agreed upon meaning.



 Jun 25 2015



prev sibling  parent reply "Mike" <none none.com>  writes:


On Thursday, 25 June 2015 at 21:06:38 UTC, Walter Bright wrote:

 On 6/25/2015 12:48 PM, Mathias Lang via Digitalmars-d wrote:

 And he's right. It is really annoying to update to a new 
 version and have
 perfectly valid and working code breaking because someone had 
 a nice idea.
 Ideally, we should only ever break code that has a bug in it.


 I've also been willing to break code if it involves significant 
 performance, usability, or correctness improvements. Renaming, 
 though, doesn't provide that.


Deprecation is *not* breakage.  Removal is.

This isn't like final-by-default where there can be only one 
default.  We can have redundant names as long as the user can 
know why they exist (documentation comment) and which is 
preferred (deprecated attribute).

I suggest deprecation without removal (i.e. removal by Walter 
only).

The .Net Framework has had deprecated names since 2.0 (10 years 
ago) and you can still use them today and likely will be able to 
in the far future. And the fact that deprecation warnings are off 
by default in D already makes it ultra-conservative.

Mike



 Jun 25 2015



  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 25 June 2015 at 23:18:13 UTC, Mike wrote:

 The .Net Framework has had deprecated names since 2.0 (10 years 
 ago) and you can still use them today and likely will be able 
 to in the far future. And the fact that deprecation warnings 
 are off by default in D already makes it ultra-conservative.


Deprecation warnings are on by default - though I think we should 
disable them by default, and start using `deprecated` as you 
suggested. I think I suggested this before as well.



 Jun 25 2015



 next sibling parent  "Mike" <none none.com>  writes:


On Thursday, 25 June 2015 at 23:20:13 UTC, Vladimir Panteleev 
wrote:


 Deprecation warnings are on by default


Delighted to be wrong.


 though I think we should disable them by default


Please don't



 Jun 25 2015



prev sibling  parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Thursday, 25 June 2015 at 23:20:13 UTC, Vladimir Panteleev 
wrote:

 On Thursday, 25 June 2015 at 23:18:13 UTC, Mike wrote:

 The .Net Framework has had deprecated names since 2.0 (10 
 years ago) and you can still use them today and likely will be 
 able to in the far future. And the fact that deprecation 
 warnings are off by default in D already makes it 
 ultra-conservative.


 Deprecation warnings are on by default - though I think we 
 should disable them by default, and start using `deprecated` as 
 you suggested. I think I suggested this before as well.


Deprecating the eager versions would go a long way to making it 
obvious which version should be used, probably such that 
ambiguous names wouldn't really matter anymore. Though I don't 
know if that would be something people would be ok with.



 Jun 25 2015



prev sibling  parent reply "Brad Anderson" <eco gnuk.net>  writes:


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.



 Jun 24 2015



  parent reply "Brad Anderson" <eco gnuk.net>  writes:


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.



 Jun 24 2015



  parent  "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>  writes:


On Wednesday, 24 June 2015 at 22:12:10 UTC, Brad Anderson wrote:

 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.


That would be inferred anyway, it's a template. But yes, `eager` 
is strictly an add-on, it doesn't after  nogc-ness of the range.



 Jun 25 2015



prev sibling next sibling parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


FWIW, I'm cool with any of the proposed options, as long as it isn't 
what's in master right now. They all have their downsides, but I can 
live with any of them.



 Jun 23 2015



prev sibling next sibling parent  "anonymous" <anonymous example.com>  writes:


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.


std.json.JsonOptions -> JSONOptions

I believe this one to be non-controversial. The rest of the 
module says "JSON" and as far as I know full capitalization of 
acronyms is the convention in phobos.

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



 Jun 24 2015



prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


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 ?



 Jun 24 2015



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


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.



 Jun 24 2015



 next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


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



 Jun 24 2015



  parent  "deadalnix" <deadalnix gmail.com>  writes:


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?



 Jun 24 2015



prev sibling  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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?



 Jun 25 2015



 next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


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.



 Jun 25 2015



  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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 
:)



 Jun 25 2015



  parent  "deadalnix" <deadalnix gmail.com>  writes:


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.



 Jun 25 2015



prev sibling  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


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



 Jun 25 2015



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


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



 Jun 25 2015



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


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.



 Jun 25 2015



  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 6/25/15 2:37 PM, deadalnix wrote:


 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.


Well, we should at least have the documentation for std.meta not 
referring to a symbol that doesn't exist there.

-Steve



 Jun 25 2015



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Thursday, 25 June 2015 at 19:22:16 UTC, Steven Schveighoffer 
wrote:

 On 6/25/15 2:37 PM, deadalnix wrote:


 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.


 Well, we should at least have the documentation for std.meta 
 not referring to a symbol that doesn't exist there.

 -Steve


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

We can discuss the details in the PR.



 Jul 01 2015



prev sibling next sibling parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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

 [...]


Same rationale as setExt/setExtension: the name difference from 
defaultExtension is abbreviating the word "Extension" to "Ext". 
Really should've been in the same thread, I simply missed it.

Suggested new name: withDefaultExtension



 Jun 25 2015



prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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



 Jun 25 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Jun 25 2015



  parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 25 June 2015 at 18:55:54 UTC, Andrei Alexandrescu 
wrote:

 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


Ah, true, I misread the documentation.



 Jun 25 2015



prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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.



 Jun 25 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


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



 Jun 25 2015



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 06/25/2015 04:24 PM, Jonathan M Davis wrote:

 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


pathAbsolutizer, pathNormalizer, pathRelativizer. :-)



 Jun 25 2015



prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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.



 Jun 25 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 6/25/15 6:45 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: Same as toLowerCase/toUpperCase.

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


There was that PR with some logic for naming the casing functions. It's 
still relevant. -- Andrei



 Jun 25 2015



  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 25 June 2015 at 18:56:39 UTC, Andrei Alexandrescu 
wrote:

 On 6/25/15 6:45 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: Same as toLowerCase/toUpperCase.

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


 There was that PR with some logic for naming the casing 
 functions. It's still relevant. -- Andrei


Jacob's PR?

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

Yes, we've discussed lowerCaser/upperCaser a lot in this thread. 
Last post in that discussion: 
http://forum.dlang.org/post/mmh47u$28bu$1 digitalmars.com



 Jun 25 2015



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 6/25/15 12:00 PM, Vladimir Panteleev wrote:

 On Thursday, 25 June 2015 at 18:56:39 UTC, Andrei Alexandrescu wrote:

 On 6/25/15 6:45 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: Same as toLowerCase/toUpperCase.

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


 There was that PR with some logic for naming the casing functions.
 It's still relevant. -- Andrei


 Jacob's PR?

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

 Yes, we've discussed lowerCaser/upperCaser a lot in this thread. Last
 post in that discussion:
 http://forum.dlang.org/post/mmh47u$28bu$1 digitalmars.com


Yah, that's the one. Glad it's under consideration - this is the only 
time it could ever be. -- Andrei



 Jun 25 2015



prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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



 Jun 25 2015



  parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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



 Jun 25 2015



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Also, making PRs for this is fine, but please hold off on pulling until Andrei 
is back and can check.



 Jun 25 2015



  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thursday, 25 June 2015 at 20:55:36 UTC, Walter Bright wrote:

 Also, making PRs for this is fine, but please hold off on 
 pulling until Andrei is back and can check.


Do you know if Andrei will be back before RC1 (or the release, at 
least)? Missing the release defeats the entire point of this 
thread, and holding up the release because we need Andrei's 
permission to rename a few functions and he is moving seems 
rather silly as well.



 Jun 25 2015



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 6/25/15 2:03 PM, Vladimir Panteleev wrote:

 On Thursday, 25 June 2015 at 20:55:36 UTC, Walter Bright wrote:

 Also, making PRs for this is fine, but please hold off on pulling
 until Andrei is back and can check.


 Do you know if Andrei will be back before RC1 (or the release, at
 least)? Missing the release defeats the entire point of this thread, and
 holding up the release because we need Andrei's permission to rename a
 few functions and he is moving seems rather silly as well.


I should have enough time to review and approve a coherent proposal. 
Thanks for your consideration. -- Andrei



 Jun 25 2015



prev sibling  parent reply "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


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

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


So, there is some discussion about these here already:

http://forum.dlang.org/post/ubfmdrorjtasgeungfin forum.dlang.org

There seems to be varying opinion, so I'm going to formally 
nominate them for renaming and get more opinions.

Rationale:

The merits of the verb-noun form ("xxxer") is that there exists 
precedent (`joiner` and `splitter`), and that they do a good job 
at describing what actually happens under the hood.

The downside is that they simply don't sound as good as some of 
the other options when using it in the code. To reiterate on a 
point from an earlier post, I think that this:

writeln(str.lowerCased.detabbed.transmogrified);

sounds better than this:

writeln(str.lowerCaser.detabber.transmogrifier);

IMO, when naming things, generally we should lean towards 
representing semantics rather than mechanics (i.e. how is this 
function going to be used, rather than what this function does 
under the hood), as that will result in more readable code.

Anyway, this is extreme bikeshedding and I won't mind too much 
leaving these alone.

Proposed new names: entabbed, detabbed, 
left/right/centerJustified, soundexed. (Existing similar names: 
`indexed`, `transposed`)



 Jun 25 2015



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Thursday, 25 June 2015 at 21:01:39 UTC, Vladimir Panteleev 
wrote:

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

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


 So, there is some discussion about these here already:

 http://forum.dlang.org/post/ubfmdrorjtasgeungfin forum.dlang.org

 There seems to be varying opinion, so I'm going to formally 
 nominate them for renaming and get more opinions.

 Rationale:

 The merits of the verb-noun form ("xxxer") is that there exists 
 precedent (`joiner` and `splitter`), and that they do a good 
 job at describing what actually happens under the hood.

 The downside is that they simply don't sound as good as some of 
 the other options when using it in the code. To reiterate on a 
 point from an earlier post, I think that this:

 writeln(str.lowerCased.detabbed.transmogrified);

 sounds better than this:

 writeln(str.lowerCaser.detabber.transmogrifier);

 IMO, when naming things, generally we should lean towards 
 representing semantics rather than mechanics (i.e. how is this 
 function going to be used, rather than what this function does 
 under the hood), as that will result in more readable code.

 Anyway, this is extreme bikeshedding and I won't mind too much 
 leaving these alone.

 Proposed new names: entabbed, detabbed, 
 left/right/centerJustified, soundexed. (Existing similar names: 
 `indexed`, `transposed`)


Well, I think that it's clear based on my previous posts that I'd 
prefer that we keep the "xxxEr" scheme, particularly when you 
consider that these functions are basically just wrappers around 
constructors for the types that do these operations.

- Jonathan M Davis



 Jun 25 2015



prev sibling next sibling parent  "Suliman" <evermind live.ru>  writes:


 IMO, when naming things, generally we should lean towards 
 representing semantics rather than mechanics (i.e. how is this 
 function going to be used, rather than what this function does 
 under the hood), as that will result in more readable code.


+1



 Jun 25 2015



prev sibling  parent reply "ixid" <adamsibson hotmail.com>  writes:


On Thursday, 25 June 2015 at 21:01:39 UTC, Vladimir Panteleev 
wrote:

 writeln(str.lowerCased.detabbed.transmogrified);

 sounds better than this:

 writeln(str.lowerCaser.detabber.transmogrifier);

 IMO, when naming things, generally we should lean towards 
 representing semantics rather than mechanics (i.e. how is this 
 function going to be used, rather than what this function does 
 under the hood), as that will result in more readable code.

 Anyway, this is extreme bikeshedding and I won't mind too much 
 leaving these alone.

 Proposed new names: entabbed, detabbed, 
 left/right/centerJustified, soundexed. (Existing similar names: 
 `indexed`, `transposed`)


They're nicer without either 'er' nor 'ed'.

writeln(str.lowerCase.detab.transmogrify);

Just as join and split are much better than the rather tortured 
joiner and splitter. That may be a cutter but I want it to cut, 
and would rather invoke it that way. The er and ed carry no 
useful information and sound clunky. A man may be a mower but I'd 
ask him to mow the field.



 Jul 02 2015



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Thursday, 2 July 2015 at 08:48:42 UTC, ixid wrote:

 They're nicer without either 'er' nor 'ed'.

 writeln(str.lowerCase.detab.transmogrify);

 Just as join and split are much better than the rather tortured 
 joiner and splitter. That may be a cutter but I want it to cut, 
 and would rather invoke it that way. The er and ed carry no 
 useful information and sound clunky. A man may be a mower but 
 I'd ask him to mow the field.


Well, for one, splitter and joiner don't do any splitting or 
joining - they simply return a range type which does so as you 
iterate over it, so that "er" is actually very related to what 
they're doing, and split and join would arguably be misnomers, 
since that implies that they actually split or join the input 
(which they don't). On the other hand, the split and join 
functions - which are eager - very much deserve their names, 
since the _do_ split and join their input respectively.

And for two, in the cases of the new functions that have been 
added recently which triggered this discussion in the first 
place, eager versions already exist which have verb names like 
you're looking for, so we have to use new names even if we wanted 
to use names like you're suggesting. So, if we were going to just 
use verbs like before, we'd have to come up with completely new 
names. And when splitter and joiner were added, split and join 
already existed, so new names were needed. So, we already have a 
precedent for adding "er" for functions which return lazy ranges, 
and it makes perfect sense to do so given that they're simply 
returning objects which do the action rather than doing the 
action themselves. They're actually more like constructors than 
normal functions.

- Jonathan M Davis



 Jul 02 2015



  parent  "ixid" <adamsibson hotmail.com>  writes:


On Thursday, 2 July 2015 at 11:04:52 UTC, Jonathan M Davis wrote:

 eager versions already exist which have verb names like you're 
 looking for, so we have to use new names even if we wanted to 
 use names like you're suggesting. So, if we were going to just 
 use verbs like before, we'd have to come up with completely new 
 names. And when splitter and joiner were added, split and join 
 already existed, so new names were needed.


I suppose my thought process is: terse but clear names like the 
original verbs are superior. The default assumption should be 
shifted from eager to lazy for how functions behave. Therefore we 
should use the best names with what we regard as the best 
functions.



 Jul 02 2015