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.

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.

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.

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

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

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.

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

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.

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

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