On Saturday, 29 November 2014 at 11:37:52 UTC, bearophile wrote:
<snip>
>
> Some of this "hibernation" could be caused by the latest "revolution" threads by Andrei. But probably there are also other causes.
>
<snip>

Yes, Andrei's ref counting and C++ compatibility, etc.

There are choices in debate to push:
a) Make D small system lang.
b) or Keep D large
I say there is more choices:
c) Both! Split it like linux: kernal and GNU. kernal is of no use
w/ out cd and cat, etc.
This way people like Andrei can help even people that use D on
real projects. In C++ we have active downstream, ex:
http://pocoproject.org/features.html. D gets stronger because of
Vibe.d. That can be encourage by spliting/reducing D 'core' to be
near useless, w/o a lib for key needed features that are in
pre-compiler and downstream ecosystem.
Win/win. Andrei's of the world could and should be encouraged as
the 'GNU' of D. I am saying 90% of 'D' should be in 'Andrei'
domain and all the sacred cows.
I'd call the non-core 'D' 'frontal lobe', the part that thinks
and D 'core' the 'lizard brain' that is just primitive/visceral.

Else the endless debate of large vs small.
I say both.

Cheers,
Vic

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. 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.

To be fair, this is already a minor annoyance between every DMD
release, that I have to go through existing D code and fix all
the nits, which are mostly phobos backwards compatibility breaks. This is making it hard to advocate to write more code in D.

It's been a while since I had to do that the last time with a new
gcc or libc release.

On Sat, 29 Nov 2014 14:00:49 +0000
Martin Nowak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Saturday, 29 November 2014 at 00:20:38 UTC, Daniel Murphy wrote:
> > I think @disabled with a custom message would be perfect for this.  static assert only works for templates.
> 
> We just need someone to implement this. https://issues.dlang.org/show_bug.cgi?id=8728
and then it will rot in bugzilla forever.

On 11/29/2014 7:56 AM, Andrej Mitrovic via Digitalmars-d wrote:
> On 11/29/14, Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> 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.
>
> You seem to create this kind of thread every other month. People
> complaint to you about A and B, you ignore it, and then when it hits
> you *personally* suddenly it's a shock to you.
>
> The fact that you think you're going to get symbol suggestions for 2
> year old code just shows how out of touch you are with the development
> process. We have a deprecation stage, and a removal stage. There's no
> way you're going to get suggestions for missing symbols for code that
> references those symbols which existed 2 years ago.

Since I participate in that process, I am hardly unaware of it :-)

ketmar:

> and then it will rot in bugzilla forever.

Not necessarily. Some things rot there, but I've seen hundreds of nice patches being merged.

Bye,
bearophile

On Sat, 29 Nov 2014 19:28:00 +0000
bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> ketmar:
> 
> > and then it will rot in bugzilla forever.
> 
> Not necessarily. Some things rot there, but I've seen hundreds of nice patches being merged.
this one is not pre-approved, so it will not get any attention.

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. 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.

Why are deprecated aliases even removed in the first place? Is there any harm in keeping them for 5+ years (undocumented of course)? There isn't any increased complexity for the user, you can completely ignore them during development, and if needed they could just go to the bottom of the scope/file hidden away from the rest of the code.

On Sat, Nov 29, 2014 at 08:32:37PM +0000, Kapps via Digitalmars-d wrote:
> 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. 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.
> 
> Why are deprecated aliases even removed in the first place? Is there any harm in keeping them for 5+ years (undocumented of course)? There isn't any increased complexity for the user, you can completely ignore them during development, and if needed they could just go to the bottom of the scope/file hidden away from the rest of the code.

Yeah we should keep deprecated aliases around for much longer than we currently do.

Having said that, though, there *are* some cases where we can't keep an old symbol around, e.g., it causes conflicts with newer overloads. But that shouldn't be a problem in this case, as it'd be clear that that particular function now requires different arguments, whereas Walter was complaining about symbols that vanished into thin air without a clue as to where they went.

There's also the issue of symbols that got moved to a different module. Sometimes leaving an alias behind is not workable, because it will cause conflicts when user code imports both modules. Unless, of course, we change overload rules to allow such apparent conflicts when they actually ultimately resolve to the same symbol in the end.


T

-- 
For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.

On 11/29/2014 1:56 PM, H. S. Teoh via Digitalmars-d wrote:
> There's also the issue of symbols that got moved to a different module.
> Sometimes leaving an alias behind is not workable, because it will cause
> conflicts when user code imports both modules. Unless, of course, we
> change overload rules to allow such apparent conflicts when they
> actually ultimately resolve to the same symbol in the end.

Aliases that resolve to the same symbol was a bug fixed long ago. If this has resurfaced, please file a bugzilla.

On Sat, Nov 29, 2014 at 02:24:46PM -0800, Walter Bright via Digitalmars-d wrote:
> On 11/29/2014 1:56 PM, H. S. Teoh via Digitalmars-d wrote:
> >There's also the issue of symbols that got moved to a different module.  Sometimes leaving an alias behind is not workable, because it will cause conflicts when user code imports both modules. Unless, of course, we change overload rules to allow such apparent conflicts when they actually ultimately resolve to the same symbol in the end.
> 
> Aliases that resolve to the same symbol was a bug fixed long ago. If this has resurfaced, please file a bugzilla.

Ah, so I'm outdated. That's good to know. :-)


T

-- 
What doesn't kill me makes me stranger.