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 (or toLowerLazy / toUpperLazy). There is precedent with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too "clever" and really just ends up causing unnecessary confusion. This is not Ruby. [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx
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 with C#'s handling of async functions; for example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming scheme seems like it's trying to be too "clever" and really just ends up causing unnecessary confusion. This is not Ruby. [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx
Yes please! If I didn't know what they were replacing, I would have no idea what withExtension, lowerCased, or upperCased meant at all. They hardly seem better than what they are replacing. Just do setExtensionLazy / toLowerLazy / toUpperLazy. It is much simpler and clearer.
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 
 with C#'s handling of async functions; for example, 
 AccessTheWebAsync or GetStringAsync[1]. Your proposed naming 
 scheme seems like it's trying to be too "clever" and really 
 just ends up causing unnecessary confusion. This is not Ruby.
 [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx
I'm not sure about this... I've seen another proposal for a "lazy" suffix in the other thread, but I think this won't be great in the long run: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. - There is no consistency with any existing naming schemes. Currently no names in Phobos contain the word "Lazy". - If std.algorithm were to follow this convention, it would have lazyJoin instead of joiner, lazySplit instead of splitter, lazyConcat OSLT instead of chain, etc. Given a typical program using std.algorithm, do you think such names would look better there than the current ones? - I'm not sure about the C# async analogy: with "async", the methods are used in a different way. The new range-based functions are used in the same way, but work on different types. Here's an example program using setExt[ension] and toLower[Case], in 4 variants... https://gist.github.com/CyberShadow/5cc7e926f566d56a672f IMHO, in this case, the "Lazy" suffix is a distracting technicality that doesn't carry its weight. Am I the only one?
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 /
 toUpperLazy). There is precedent with C#'s handling of async functions; for
 example, AccessTheWebAsync or GetStringAsync[1]. Your proposed naming
 scheme seems like it's trying to be too "clever" and really just ends up
 causing unnecessary confusion. This is not Ruby.
 [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx
I'm not sure about this... I've seen another proposal for a "lazy" suffix in the other thread, but I think this won't be great in the long run: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. - There is no consistency with any existing naming schemes. Currently no names in Phobos contain the word "Lazy". - If std.algorithm were to follow this convention, it would have lazyJoin instead of joiner, lazySplit instead of splitter, lazyConcat OSLT instead of chain, etc. Given a typical program using std.algorithm, do you think such names would look better there than the current ones? - I'm not sure about the C# async analogy: with "async", the methods are used in a different way. The new range-based functions are used in the same way, but work on different types. Here's an example program using setExt[ension] and toLower[Case], in 4 variants... https://gist.github.com/CyberShadow/5cc7e926f566d56a672f IMHO, in this case, the "Lazy" suffix is a distracting technicality that doesn't carry its weight. Am I the only one?
+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 
 with C#'s handling of async functions; for example, 
 AccessTheWebAsync or GetStringAsync[1]. Your proposed naming 
 scheme seems like it's trying to be too "clever" and really 
 just ends up causing unnecessary confusion. This is not Ruby.
 [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx
I'm not sure about this... I've seen another proposal for a "lazy" suffix in the other thread, but I think this won't be great in the long run: - Ultimately, we want to encourage use of the lazy versions, in the same way that e.g. std.algorithm and std.range are encouraged over eager operations for arrays. - There is no consistency with any existing naming schemes. Currently no names in Phobos contain the word "Lazy".
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).
 - I'm not sure about the C# async analogy: with "async", the 
 methods are used in a different way. The new range-based 
 functions are used in the same way, but work on different types.

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

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

 IMHO, in this case, the "Lazy" suffix is a distracting 
 technicality that doesn't carry its weight. Am I the only one?
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
 toLowerLazy / toUpperLazy). There is precedent with C#'s handling of
 async functions; for example, AccessTheWebAsync or GetStringAsync[1].
 Your proposed naming scheme seems like it's trying to be too "clever"
 and really just ends up causing unnecessary confusion. This is not Ruby.
 [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx
+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