Long time not heard from each other. ;)

On Monday, 16 September 2013 at 19:28:22 UTC, Andrei Alexandrescu wrote:
> On 9/16/13 11:56 AM, Namespace wrote:
>> I hate this NotNull struct hack. It is the same crap as the current
>> scope solution.
>
> Scoped variables in the language were a lot worse.
Why? The escaping problem could be solved, not?
Wouldn't it be better, if scope would stay and would be rewritten internal to the library solution? The compiler could then detect and solve many of the current problems.

>
>> BTW: I'm curious which built-in feature will be removed
>> next, maybe AA?
>
> If we're diligent and lucky, hopefully.
That was a joke of me. So I hope that is also a joke. Otherwise it would be a huge step in the C++ direction.
If it wasn't a joke: what are the rationale for that?

>
>> An annotation like Foo! f would be much nicer than NotNull!Foo or
>> @NotNull Foo, but it would be an agreement.
>
> Is annotation the only or main problem?
My problem are the nullable classes. But I would be happy with an annotation.
>
>> And I agree absolute, to disable default CTor's by struct's was a huge
>> mistake. But D is full of those. ;)
>
> They are not disabled. It seems many people are having trouble with getting default constructors to evaluate code, so I assume you mean that. One possibility (or first step) would be to relax the language to allow CTFE-executable code in default constructors.
>
>
> Andrei
Example?

On Monday, 16 September 2013 at 19:21:47 UTC, H. S. Teoh wrote:
> On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote:
> [...]
>> I hate this NotNull struct hack. It is the same crap as the current
>> scope solution. BTW: I'm curious which built-in feature will be
>> removed next, maybe AA?
> [...]
>
> That wouldn't be a bad idea, actually. The current AA implementation is
> so horribly broken, and so wrong in so many ways (there are at least 75
> bugs related to AA's, some of the worst of which are 11037, 11025,
> 10916, 10525, 10381, 10380, 10046, just to name a few), that it would do
> a world of good to get rid of them altogether, and then reintroduce a
> properly-designed library solution for them.
>
> Of course, in the meantime everyone whose code breaks because of that
> will form a mob to lynch me, so I'll have to survive long enough to get
> the library solution working first. :-P
>
>
> T

Built-in Arrays have also problems.
What should we do? Remove and rewrite them also as library solution?
With Arrays and AA's we would lose a lot of good differences to C++. Why should anyone switch to D if it is nothing else as a new C++?

On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
> Why should anyone switch to D if it is nothing else as a new C++?


It's worth pointing out that the library AAs proposed here would still have the same syntax as the built-in ones now.

int[string] a;

would just be magically rewritten into

AssociativeArray!(int, string) a;

and ["one" : 1, "two" : 2], would just become something like AALiteral(["one", "two"], [1, 2]);, or whatever, I'm not sure exactly what they were going to do there.


Anyway though, all the sugar is still there, just a new implementation as a regular D struct instead of a bunch of calls to _d_assocarray and the other dozen magic functions and typeinfo things it uses now.


BTW part of the bugginess is because this move to the library was half-assed. It does do the AssocativeArray rewrite... but it also still uses the magic functions.

So there's all kinds of weird crap going on that can make programs fail to link and other bugs since we've been stuck in this no-man's land for years.

On Monday, 16 September 2013 at 20:09:53 UTC, Adam D. Ruppe wrote:
> On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
>> Why should anyone switch to D if it is nothing else as a new C++?
>
>
> It's worth pointing out that the library AAs proposed here would still have the same syntax as the built-in ones now.
>
> int[string] a;
>
> would just be magically rewritten into
>
> AssociativeArray!(int, string) a;
>
> and ["one" : 1, "two" : 2], would just become something like AALiteral(["one", "two"], [1, 2]);, or whatever, I'm not sure exactly what they were going to do there.

Then of course I have not said anything.
The same thing I would suggest for scope. It exists as a library solution and is rewritten magical.

On Monday, 16 September 2013 at 20:15:26 UTC, Namespace wrote:
> On Monday, 16 September 2013 at 20:09:53 UTC, Adam D. Ruppe wrote:
>> On Monday, 16 September 2013 at 19:58:51 UTC, Namespace wrote:
>>> Why should anyone switch to D if it is nothing else as a new C++?
>>
>>
>> It's worth pointing out that the library AAs proposed here would still have the same syntax as the built-in ones now.
>>
>> int[string] a;
>>
>> would just be magically rewritten into
>>
>> AssociativeArray!(int, string) a;
>>
>> and ["one" : 1, "two" : 2], would just become something like AALiteral(["one", "two"], [1, 2]);, or whatever, I'm not sure exactly what they were going to do there.
>
> Then of course I have not said anything.
> The same thing I would suggest for scope. It exists as a library solution and is rewritten magical.

And maybe also for delete: we need something to delete the memory manually.

On Monday, 16 September 2013 at 20:16:45 UTC, Namespace wrote:
> And maybe also for delete: we need something to delete the memory manually.

And we need built-in memory allocators, not only GC.

On 09/16/13 21:58, Namespace wrote:
> On Monday, 16 September 2013 at 19:21:47 UTC, H. S. Teoh wrote:
>> On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote: [...]
>>> I hate this NotNull struct hack. It is the same crap as the current scope solution. BTW: I'm curious which built-in feature will be removed next, maybe AA?
>> [...]
>>
>> That wouldn't be a bad idea, actually. The current AA implementation is so horribly broken, and so wrong in so many ways (there are at least 75
[...]
> Built-in Arrays have also problems.
> What should we do? Remove and rewrite them also as library solution?

Yes. Without any doubt whatsoever. [1]

> With Arrays and AA's we would lose a lot of good differences to C++.

Removing hardwired builtin magic does not imply syntax changes. And, the syntax that matters in practice is not the declarations, but the literals, which is where the language could do much better anyway.

> Why should anyone switch to D if it is nothing else as a new C++?

D is not only about arrays.

artur

[1] Obviously, not a practical short term option for the existing D2 language.
    That's probably clear from the context, and the question was meant to be
    rhetorical -- but it could actually be done and would make sense; it's just
    not a change that would make enough of a difference on its own; the cost
    would be to high.

> D is not only about arrays.
It's a big plus. ;)


> [1] Obviously, not a practical short term option for the existing D2 language.
>     That's probably clear from the context, and the question was meant to be
>     rhetorical -- but it could actually be done and would make sense; it's just
>     not a change that would make enough of a difference on its own; the cost
>     would be to high.

Why to high? Too much compiler magic or dmd internal dependences?

On Mon, Sep 16, 2013 at 10:38:58PM +0200, Namespace wrote:
> >D is not only about arrays.
> It's a big plus. ;)
> 
> 
> >[1] Obviously, not a practical short term option for the existing D2 language.  That's probably clear from the context, and the question was meant to be rhetorical -- but it could actually be done and would make sense; it's just not a change that would make enough of a difference on its own; the cost would be to high.
> 
> Why to high? Too much compiler magic or dmd internal dependences?

I disagree that it's too high. It just needs *somebody* with the right knowledge about DMD internals (and enough free time on their hands >:-)) to pull it off.

The problem with the current AA implementation is that it's schizophrenically split across DMD, aaA.d, and object.di. Martin Nowak recently cleaned it up somewhat (removed the horrible code duplication between aaA.d and object.di that used to be there) but fundamental issues remain, a major cause of which is the fact that aaA.d operates on typeinfo's rather than the direct types (this isn't a problem in and of itself, but the problem is that *only* AA keys have the benefit of their typeinfo's being available to AA functions, which means AA *values* that require non-trivial postblits and other such things are fundamentally broken in horrible ways).

Moreover, DMD still retains way too much knowledge about AA internals, so sometimes it gets mapped to struct AssociativeArray, sometimes directly mapped to aaA.d, and sometimes a buggy inconsistent mixture of both. And the code that emits these different schizophrenic parts are sprinkled all over different unrelated parts of DMD, making any cleanup attempt rather challenging, to say the least. And of course, any non-correspondence between any of these parts means yet another AA bug waiting to happen.

Cleaning up this mess once and for all will unquestionably do a world of good to D.


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel

On 09/16/13 22:38, Namespace wrote:
>> [1] Obviously, not a practical short term option for the existing D2 language.
>>     That's probably clear from the context, and the question was meant to be
>>     rhetorical -- but it could actually be done and would make sense; it's just
>>     not a change that would make enough of a difference on its own; the cost
>>     would be to high.
> 
> Why to high? Too much compiler magic or dmd internal dependences?

Too much (language) change for too little gain; there are many, many much more important things that need to be fixed. Being able to have several user-defined kinds of arrays is a nice-to-have feature, but not one that determines whether the language is usable or not.

artur