On Monday, 13 October 2014 at 16:00:21 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 12 October 2014 at 18:47:31 UTC, Walter Bright wrote:
>> Deprecation is a way station on the way to removal. Warnings are not necessarily headed that way.
>
> Indeed, but the choice of _when_ to remove can in practice be quite free, no?  It would be possible to put in place this deprecation warning and wait for years before acting on it.

This is one thing I'd love major versions to be used for. Deprecate bunch of things iteratively, remove them completely in D 3.xx.yy ; aggregate bunch of new deprecated things and release D 4.xx.yy etc.

On Monday, October 13, 2014 19:59:13 deadalnix via Digitalmars-d wrote:
> The right path forward seems to be deprecating now, but not removing before dfix can do something good about it.

I don't know that we need to wait for dfix, but we never remove deprecated stuff from the language very quickly anyway. So, I expect that it'll be around for at least a year or two before we look at actually removing it, so dfix will presumably be able to take care of it long before we're looking to remove it anyway.

- Jonathan M Davis

On Monday, 13 October 2014 at 17:15:34 UTC, John Colvin wrote:
> The only argument that's left is: "I don't mind you breaking my code by fixing bugs in the implementation, but I do mind when it's for cleaning/changing the language/phobos". In light of recent comments from heavyweight users saying "please break my code in the name of improving the language and libraries", I don't think it holds much water.

Well, in this case we don't necessarily need to break anyone's code, it would be possible to stop at deprecation.

But generally speaking, I agree with you, which is why I was hoping to move the debate to, "What are the circumstances under which these breaks are possible," rather than "Should we/shouldn't we".

"John Colvin"  wrote in message news:ljjtmnnckwzenvhawawx@forum.dlang.org...

> [2] By easily managed I don't mean sed-able, or even tooling-fixable. For me it pivots on being able to maintain one code-base that will compile with multiple compiler versions. An example where this fails: @nogc, being an attribute, isn't aliasable, meaning you can't version it out neatly.

There is nothing stopping you from not supporting @nogc until your oldest supported dmd version has it.  I agree with your requirement, but this is not a good example of it.  A better example would be requiring nothrow annotations on inline asm blocks, because the old code won't compile with newer dmds and the new code won't compile with older ones. 

"Jonathan M Davis via Digitalmars-d"  wrote in message news:mailman.768.1413233509.9932.digitalmars-d@puremagic.com...

> I don't know that we need to wait for dfix, but we never remove deprecated
> stuff from the language very quickly anyway. So, I expect that it'll be around
> for at least a year or two before we look at actually removing it, so dfix
> will presumably be able to take care of it long before we're looking to remove
> it anyway.

And even without dfix, non-trivial year-old code rarely compiles with the latest frontend. 

On Tuesday, 14 October 2014 at 16:11:34 UTC, Daniel Murphy wrote:
> "John Colvin"  wrote in message news:ljjtmnnckwzenvhawawx@forum.dlang.org...
>
>> [2] By easily managed I don't mean sed-able, or even tooling-fixable. For me it pivots on being able to maintain one code-base that will compile with multiple compiler versions. An example where this fails: @nogc, being an attribute, isn't aliasable, meaning you can't version it out neatly.
>
> There is nothing stopping you from not supporting @nogc until your oldest supported dmd version has it.

Good point.

It would be nice to be able to take advantage of new features though, whilst maintaining backward compatibility. Also, a 3rd party project could make @nogc a requirement, meaning I have to choose between compatibility with older compilers or with that 3rd party code. Alias-able attributes would help a lot.

> I agree with your requirement, but this is not a good example of it.  A better example would be requiring nothrow annotations on inline asm blocks, because the old code won't compile with newer dmds and the new code won't compile with older ones.

Yes, that's a more concrete example, thanks.

On Sat, 11 Oct 2014 13:47:55 +0100, Martin Nowak <code+news.digitalmars@dawg.eu> wrote:

> https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353
>
> There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners.
> There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners.
>
> Let's continue with the following steps.
> - add RHS/LHS function qualifiers to D's style guide
> - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers)
> - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1)
>
> Then we might revisit the topic in 6 month and see whether we have better arguments now.

+1

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code@dawg.eu> wrote:
> Would this affect your code?

Probably, but I have no D code of any size to care about.

> Do you think it makes your code better or worse?

Better.

> Is this just a pointless style change?

Nope.

> Anything else?

Only what you said in summary to this thread (I am waay late to this party)

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:
> On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code@dawg.eu> wrote:
>> Would this affect your code?
No
>> Do you think it makes your code better or worse?
Better. More clear
>> Is this just a pointless style change?
No

On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:
> On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak <code@dawg.eu> wrote:
>> Would this affect your code?
>
> Probably, but I have no D code of any size to care about.

Would this change make you to write more code in D?