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

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.

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

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.

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?

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.

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

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

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

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