On 2014-11-30 16:36, H. S. Teoh via Digitalmars-d wrote:

> I thought dlang.org already has a page that lists language & library
> changes for each of the recent releases?

We have only had that for a couple of releases and not the latest release. No one wrote that document for the latest release and it, apparently, was more important to get the new release out.

Also, they only list changes. There's no indication if it's a breaking change or not.

> Good idea! We should archive docs from older versions of Phobos and make
> them accessible on dlang.org. I'm working on revamping some parts of the
> Phobos docs build; once that's in, it might not be too hard to make it
> also generate docs for older releases.

Yeah, it needs to be possible to access the documentation for an arbitrary version of D at dlang.org.

-- 
/Jacob Carlborg

On Monday, December 01, 2014 09:57:33 bearophile via Digitalmars-d wrote:
> Walter Bright:
>
> > Thanks! I like pressing existing features into use over inventing new ones :-)
>
> The existing feature to be used is @deprecated, it's more self-documenting and it was designed for that purpose. Using that special assert is just a workaround. No one was suggesting to invent new feature, but to add a string argument to the right feature to use.

The primary difference is that deprecated symbols are still usable, whereas a disabled wouldn't be - nor would a function with static assert(0) in it be usable. And if a something in Phobos is usuable, then we need to maintain it, and that's a problem if we're trying to get rid of it. A function that results in a static assertion when used is still a problem, because it does leave cruft in the library, and it creates symbol conflicts with any symbols which happen to use the same name, but it's still better than leaving something as deprecated permanently.

- Jonathan M Davis

Jonathan M Davis:

> but it's still better than leaving something as deprecated permanently.

Right, sorry, I meant disabled.
But I don't like to keep those things disabled permanently, they eventually should be removed.

Bye,
bearophile

On Monday, December 01, 2014 11:21:23 bearophile via Digitalmars-d wrote:
> Jonathan M Davis:
>
> > but it's still better than leaving something as deprecated permanently.
>
> Right, sorry, I meant disabled.
> But I don't like to keep those things disabled permanently, they
> eventually should be removed.

I agree. I do think that we should strive for stability and backwards compatibility, but if we're getting rid of something, then I think that we should actually get rid of it at some point. That's part of why we have the deprecation process that we have.

- Jonathan M Davis

On 2014-11-29 00:33, 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. 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 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.

Every single release since at least DMD 2.050 has broken DWT. Most of these issues were language changes and not renamed symbols in Phobos.

-- 
/Jacob Carlborg

On 11/30/14 6:03 PM, Walter Bright wrote:
> On 11/30/2014 7:28 AM, H. S. Teoh via Digitalmars-d wrote:
>> I think the complaint was not so much the fact that the code broke, but
>> the fact that it broke *without any clue as to how to fix it*.
>
> Yup. Consider the fnmatch => globMatch change. Just edit the name,
> right? Easy-peesy, right? But:
>
> 1. the guy given the job of updating the software is not the guy who
> wrote it - he doesn't know what the code is intending to do
>
> 2. He gets "fnmatch is undefined"
>
> 3. there's no documentation for fnmatch anymore. He has no idea what
> fnmatch is supposed to do. Now he's got to embark on some sort of
> forensic search through old versions of the compiler, and not having
> much clue which ones to look at
>
> 4. he figures out what it does, then starts poking through the Phobos
> documentation looking for something that might work
>
> 5. he finds globMatch, it looks like it'll work
>
> 6. hopefully he's got a good test suite to verify that it is actually
> the correct replacement
>
> A simple name change has turned into a fair amount of work.
>
>
>> Now, if we had something like @disable with an optional message, we
>> could do
>> something like:
>>
>>     @disabled("Please use globMatch instead") auto fnmatch(...);
>>
>> At least in theory, this would fix the problem. Of course, in practice,
>> things rarely work out so nicely except in retrospect. :-P
>
> Keeping around a deprecated alias translating the old symbol to the new
> one is a good approach. For a more detailed message, instead of the
> @disabled enhancement, a simpler way is:
>
>    void fnmatch()(...) {
>      static assert(0, "use globMatch instead of fnmatch");
>    }

I propose a new feature:

/++
    globMatch does blah blah blah
    Oldname: fnmatch
+/

dmd -checkoldnames myoldproject.d

Error: fnmatch not defined. Note: globMatch says that it used to be called fnmatch.

It isn't often we change names of things just to change the name. And if we do, it's because the name is so bad. I agree with bearophile, the name of things is *very* important, and shouldn't be prevented from changing.

Note, we could add ddoc comments for moving symbols to different modules too.

/++
 Movedname: sleep => core.sys.posix.unistd.sleep
+/

I can't help but think that some sort of version(CompiledWith2065) statements wouldn't help, but they would be really messy. I like the idea of including old names in the docs, because that's really where it should be, and it adds a note in the documentation. It can also be amended retroactively when people find those cases, and it's documentation. Documentation changes don't require any unit tests or special explanations, they are just documents.

Making it usable by automated tools can only help.

-Steve

On Mon, Dec 01, 2014 at 03:51:48AM -0800, Jonathan M Davis via Digitalmars-d wrote:
> On Monday, December 01, 2014 11:21:23 bearophile via Digitalmars-d wrote:
> > Jonathan M Davis:
> >
> > > but it's still better than leaving something as deprecated permanently.
> >
> > Right, sorry, I meant disabled.
> > But I don't like to keep those things disabled permanently, they
> > eventually should be removed.
> 
> I agree. I do think that we should strive for stability and backwards compatibility, but if we're getting rid of something, then I think that we should actually get rid of it at some point. That's part of why we have the deprecation process that we have.
[...]

I agree that if we're gonna remove something, we should actually *remove* it, not just leave an empty husk behind forever cluttering the code. That's why I suggested lengthening the deprecation cycle. But OTOH, how long can you drag out the deprecation process before it essentially becomes needless cruft that we're forced to carry around "almost forever"?


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5

On Monday, 1 December 2014 at 11:52:04 UTC, Jonathan M Davis via
Digitalmars-d wrote:
> On Monday, December 01, 2014 11:21:23 bearophile via
> Digitalmars-d wrote:
>>
>> Right, sorry, I meant disabled.  But I don't like to keep those
>> things disabled permanently, they eventually should be removed.
>
> I agree. I do think that we should strive for stability and
> backwards compatibility, but if we're getting rid of something,
> then I think that we should actually get rid of it at some
> point. That's part of why we have the deprecation process that
> we have.
>
Thinking along these lines, would it be possible to have something like a deprecation module (core.deprecations?) that you can import (temporarily) for updating old code? At the very least, it seems it would be possible to alias and warn with pragma for some changed names, and error at compile time with an informative message otherwise.

Maybe feed it a version the project last built with to narrow what changes might be.  In a more magical future, the compiler might automatically import it with a switch and obviate the need for manually changing files, or tools could be built to use it finding trouble spots and automated updates (more for dfix, I suppose).

-Wyatt

On 12/1/2014 8:17 AM, Wyatt wrote:
> Thinking along these lines, would it be possible to have something like a
> deprecation module (core.deprecations?) that you can import (temporarily) for
> updating old code? At the very least, it seems it would be possible to alias and
> warn with pragma for some changed names, and error at compile time with an
> informative message otherwise.


Not exactly what you suggest, but:


http://code.dlang.org/packages/undead

https://github.com/DigitalMars/undeaD

On 12/1/2014 1:57 AM, bearophile wrote:
> Walter Bright:
>
>> Thanks! I like pressing existing features into use over inventing new ones :-)
>
> The existing feature to be used is @deprecated, it's more self-documenting and
> it was designed for that purpose. Using that special assert is just a
> workaround. No one was suggesting to invent new feature, but to add a string
> argument to the right feature to use.

That is inventing a new feature.