On Sun, 30 Nov 2014 18:01:34 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> On Sun, Nov 30, 2014 at 03:03:37PM -0800, Walter Bright via Digitalmars-d wrote: [...]
> > 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");
> >   }
> [...]
> 
> That's a good idea.
> 
> Keep in mind, though, that in this particular case, std.path was essentially replaced wholesale, so does that mean that every time we replaced a module, we have to keep the entire old set of symbols around basically forever?
this whole thing is a work for dfix, i believe. there's no need to keep alot of junk in libraries where dfix can do much better work.

On 11/30/2014 6:01 PM, H. S. Teoh via Digitalmars-d wrote:
> On Sun, Nov 30, 2014 at 03:03:37PM -0800, Walter Bright via Digitalmars-d wrote:
> [...]
>> 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");
>>    }
> [...]
>
> That's a good idea.

Thanks! I like pressing existing features into use over inventing new ones :-)


> Keep in mind, though, that in this particular case, std.path was
> essentially replaced wholesale, so does that mean that every time we
> replaced a module, we have to keep the entire old set of symbols around
> basically forever?

Why not?

D's module system is very good at avoiding name collisions, and dealing with them when they do arise. Not only that, it's probably a good idea for new modules in Phobos to avoid collisions with old names, even when the old names are removed, so that people are not confused when they try to recompile old projects.

On Sunday, November 30, 2014 23:19:19 weaselcat via Digitalmars-d wrote:
> I suggest everything be made immutable by default ;)

That probably would have been too much of a divergence from D's C/C++ roots to go over very well, but it's something that we would probably consider if we were starting from scratch - similarly, pure and @safe should probably be the default for functions, but it's far too late now.

- Jonathan M Davis

On Sun, Nov 30, 2014 at 08:52:33PM -0800, Jonathan M Davis via Digitalmars-d wrote:
> On Sunday, November 30, 2014 23:19:19 weaselcat via Digitalmars-d wrote:
> > I suggest everything be made immutable by default ;)
> 
> That probably would have been too much of a divergence from D's C/C++ roots to go over very well, but it's something that we would probably consider if we were starting from scratch - similarly, pure and @safe should probably be the default for functions, but it's far too late now.
[...]

If we were ever to have a D3, I'd propose that one of the first things to do is to make everything pure and @safe by default.


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?

01-Dec-2014 01:44, Walter Bright пишет:
> On 11/30/2014 12:28 PM, Dmitry Olshansky wrote:
>> 30-Nov-2014 23:22, Walter Bright пишет:
>>> On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
>>>> 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.
>>>
>>> I decided to try and update DMDScript from D1 to D2. Thousands and
>>> thousands of error messages :-(
>>>
>>
>> Even back in 2010 it took about 10 evenings to get it to "runnable"
>> state. Then
>> another ~20 evenings to fix most of bugs, including semantic errors
>> and GC
>> collecting live objects.
>>
>> You may want to check my fork that used to compile with dmd 2.058 or smth
>> (whatever was actual in 2012). Might help to assess the amount of work...
>> https://github.com/DmitryOlshansky/DMDScript
>>
>> It at least passed about 90% (most fails in library tests) of 2012
>> Google's
>> Spuntik JavaScript test.
>>
>
> Do you mind if I simply merge your fork into
> https://github.com/DigitalMars/DMDScript ?

Not at all, in fact, that would be awesome.

-- 
Dmitry Olshansky

On 2014-12-01 00:03, Walter Bright wrote:

> 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

$ git log -S 'fnmatch'

Is a good command for that.

-- 
/Jacob Carlborg

On 2014-12-01 00:03, Walter Bright wrote:

> 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");
>    }

That doesn't work for virtual methods. Although I think they are quite few in Phobos.

-- 
/Jacob Carlborg

On Sunday, November 30, 2014 07:28:57 H. S. Teoh via Digitalmars-d wrote:
> On Sun, Nov 30, 2014 at 03:03:23AM -0800, Jonathan M Davis via Digitalmars-d wrote:
> > To really have full stability, we'd pretty much have to freeze everything and change nothing beyond bug fixes, and we're definitely not doing that. Heck, simply introducing a new function to Phobos can break existing code, because it can create a symbol conflict.
>
> Speaking of which, this problem is made a lot worse than it could be, because currently private symbols in imported modules are included in the overload set, so introducing a *private* symbol can break unrelated user code downstream. Ugh.

Yeah, and AFAIK, no one ever managed to convince Walter that that needed to be changed. There were DIPs on the matter, but I don't recall if any made it to the PR stage or not. I know that Martin was looking at it at one point, and he wrote one of the DIPs, but AFAIK, he hasn't touched the issue recently.

> > It's an easy fix, but stuff like that makes it nigh on impossible to guarantee that we won't break two-year old code.
> [...]
>
> 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*. 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

That would create symbol conflicts as long as the symbol was kept around, which is more of a problem in some cases than others. It also leaves cruft in the library. So, ideally, we wouldn't leave stuff like that around, but as the language and standard library mature, we are going to need to seriously look at having two year old code work with an up-to-date compiler and standard library. Thus far, the approach has been that folks really need to be maintaining their code at least occasionally, and we've supported moving code forward clearly via the deprecation cycle, but code that isn't touched for years wasn't really even considered a legitimate use case by many of us - and yebblie's suggestion of updating to an intermediary compiler does solve the problem rather nicely.

So, I don't know. As a maintainer of Phobos, I'd much prefer to not leave cruft around, since it does make the library worse for anyone who is maintaining their code, and I don't know how much sympathy I have when code isn't even built with a newer compiler for over two years. But we do want to be a lot more stable than we are...

Maintaining stability while avoiding stagnation and cruft is always a challenge.

- Jonathan m Davis

On 12/1/2014 12:22 AM, Jacob Carlborg wrote:
> On 2014-12-01 00:03, Walter Bright wrote:
>
>> 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
>
> $ git log -S 'fnmatch'
>
> Is a good command for that.
>

I didn't know that. Thanks for the tip!

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.


> Why not?

Because it's ugly, and ugly things usually later manage to find ways to give you troubles.


> it's probably a good idea for new modules in Phobos to avoid collisions with old names, even when the old names are removed, so that people are not confused when they try to recompile old projects.

In few (not common) cases it's better to re-use an old name for different better purposes.

Bye,
bearophile