"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.2437.1417219611.9932.digitalmars-d@puremagic.com...

> From an end user's POV, though, two years does seem like a short time. I
> mean, I have C/C++ projects dating from 20 years ago, and you wouldn't
> believe it, but almost all of them compile with no change on a modern
> compiler. Granted, the comparison isn't altogether fair, since D is
> changing a lot faster than C/C++, but still, 2 years is quite short from
> that POV. Not everybody is constantly trying to compile code with git
> HEAD and fixing compiling errors on every personal pet project they
> have, that, on the off-chance, might stop compiling after 2 years.

I don't think it's reasonable to support those expectations in phobos.  You don't need to constantly compile with git HEAD, just upgrade in smaller steps than 2 years.

> Perhaps it's time to reconsider the length of the deprecation cycle,
> from an end user's POV, rather than from the POV of the D devs who can't
> wait to junk the old stuff and move on to the new.

Maintaining only junk has a cost, and development is slow enough as it is.

> Alternatively, we should have a "compatibility mode" for the compiler /
> Phobos, where certain parts of the code are version'd out as they get
> deprecated, but you can get them back by using an appropriate version
> declaration:
>
> This works reasonably well for Phobos, but I don't know how to do this
> in the compiler without ending up with an ugly plate of unmaintainable
> spaghetti.

I don't think it works well for either, but it really doesn't work for the compiler.  Everything depends on everything else and often motivation for actually getting around to removing features comes from how much of a pain they are to maintain. 

"Walter Bright"  wrote in message news:m5b2dc$1f4j$1@digitalmars.com...

> On 11/28/2014 3:46 PM, Daniel Murphy wrote:
> > Two years is too old, you skipped all the deprecation stages.
>
> My favorite unhelpful message:
>
>    src/med/spawn.d(62): Error: undefined identifier sleep, did you mean template slurp(Types...)(string filename, in char[] format)?
>
> Grepping around revealed that sleep() had migrated to core.sys.posix.unistd

I don't know the history on that one, but why did you go straight to the latest compiler?  Stepping through (some of) the last two years' releases would quite likely have been the same experience, but with better errors from the deprecation stages. 

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.2435.1417218926.9932.digitalmars-d@puremagic.com...

> Perhaps what we need is, after a symbol has passed the deprecation
> cycle, replace its original definition with a static assert(0).
> Something like this:

I think @disabled with a custom message would be perfect for this.  static assert only works for templates. 

On 11/28/2014 4:19 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:m5b2dc$1f4j$1@digitalmars.com...
>
>> On 11/28/2014 3:46 PM, Daniel Murphy wrote:
>> > Two years is too old, you skipped all the deprecation stages.
>>
>> My favorite unhelpful message:
>>
>>    src/med/spawn.d(62): Error: undefined identifier sleep, did you mean
>> template slurp(Types...)(string filename, in char[] format)?
>>
>> Grepping around revealed that sleep() had migrated to core.sys.posix.unistd
>
> I don't know the history on that one, but why did you go straight to the latest
> compiler?  Stepping through (some of) the last two years' releases would quite
> likely have been the same experience, but with better errors from the
> deprecation stages.

Can't tell users to do that. It's not reasonable.

"Walter Bright"  wrote in message news:m5b5ma$1hfj$1@digitalmars.com... 

> Can't tell users to do that. It's not reasonable.

I don't see why not.

On Sat, 29 Nov 2014 12:04:26 +1100
Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> "Walter Bright"  wrote in message news:m5b5ma$1hfj$1@digitalmars.com...
> 
> > Can't tell users to do that. It's not reasonable.
> 
> I don't see why not.
they will lose all the fun figuring out what that code was meant to do and why they must slurp now.

Walter Bright:

> Can't tell users to do that. It's not reasonable.

A possible solution: in the standard D distribution you put two or more versions (duplicated) of Phobos (switchable with a compiler switch), so people that don't bother to follow the deprecation cycles can compile even 15 years old D code.

Bye,
bearophile

"bearophile"  wrote in message news:rgoeylyaqzlvtgyafsqj@forum.dlang.org...

> A possible solution: in the standard D distribution you put two or more versions (duplicated) of Phobos (switchable with a compiler switch), so people that don't bother to follow the deprecation cycles can compile even 15 years old D code.

Why not just tell people to use dvm?  No reason to make the release zip more gigantic. 

On Sat, Nov 29, 2014 at 01:11:54AM +0000, bearophile via Digitalmars-d wrote:
> Walter Bright:
> 
> >Can't tell users to do that. It's not reasonable.
> 
> A possible solution: in the standard D distribution you put two or more versions (duplicated) of Phobos (switchable with a compiler switch), so people that don't bother to follow the deprecation cycles can compile even 15 years old D code.
[...]

The problem with that, is that Phobos often doesn't even compile with the previous release of DMD (or, for that matter, a commit prior to a PR that spans both dmd and Phobos), so it's anyone's guess what an older version of Phobos would do when compiled with a newer compiler.

Unless, of course, you maintain the old version enough to keep it compilable with the current compiler. But that's a lot of additional maintenance work.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel

On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
> Just for fun, I've decided to try and get MicroEmacs in D added to the dub registry. The last time it compiled was 2 years ago.
>
> I wound up with at least a dozen references to Phobos names that have disappeared.

Only 12?  That's pretty damn good.

No corrective action was indicated, just
> "undefined symbol". I have to go refigure out what the code was trying to do, and go poking through the Phobos documentation to see what will work today.
>
> I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old.

I don't expect any 2 year old software to work with the latest tools. All of my products are tied to the compiler they are built with.  I don't upgrade until I'm ready to allocate resources to refactoring and testing.  I'm still using Visual Studio 6.0 on some projects.

>
> I fully understand how unfriendly this is to users and how discouraging it can be to have their recently working code shattered and scattered. We need to do a lot better.

Users' migration to the latest tools is in their hands to handle how they wish. It's their responsibility.
* They don't have to upgrade.
* There are beta cycles for them to test with to mitigate risk and inform maintainers of problems.
* The project is open source, and developed right out in the open, so all changes are documented, the source code is available, and users have the opportunity to influence the outcome.
* Each version is segregated into its own branch, and with diff tools, all changes can be seen relatively easily.
* I could go on.

I'm not buying the argument that D shouldn't evolve because users are carelessly upgrading their tools and expecting everything to just work.

Mike