D parsing

[Andrei Alexandrescu]

On 11/11/13 9:11 PM, deadalnix wrote:
> On Tuesday, 12 November 2013 at 02:34:52 UTC, Andrei Alexandrescu wrote:
>> No need to be snarky about it. The point here is that there is
>> significant difficulty to remove features that already exist and are
>> useful, which changes the game considerably.
>>
>> Andrei
>
> That is true. However, please understand that this is extremely
> frustrating to have a lot of gadget features that solve a specific issue
> when much more generic solutions exists, and when these gadgets actually
> makes it more difficult to introduce the proper features.

Frustration is inappropriate. Probably "bummed" would be more fit for 
the situation. (Which I am not, but that's a different story; I 
personally don't think macros are all they're cracked to be.)

We did not have a macro-based solution when D was being invented, and I 
don't think there's a lot of glory in seeing patterns for doing things 
differently after the language has been in use for a while. There's a 
whole water under the bridge between now and then.

> If we put aside the AST macro thing (granted we have a swiss army knife
> of gadgets for many of its typical uses cases), several other skeleton
> don't want to stay in the closet.
>
> If I has to pick 2:
> tail qualified type parameter are one. It is impossible to have a use
> defined type that behave as slices/pointers. That is showstopper for a
> proper collection library. I have only ugly solution to propose to that
> now. Lately, I was plying with thing along the lines of struct S[T] {
> auto foo() const[T] { ... } } I'm afraid that what already exist in that
> area makes things quite difficult.
>
> The lack of qualifier for ownership, which makes concurrency and
> interface between manual memory management and GC tedious. For that one,
> isolated seems the way to go.
>
> These same issue continue to pop up in many different forms (for
> instance, see Kenji's DIP, where he is trying to hack around some gadget
> to unique postblit work).

Our goals for the time being are to improve stability, close gaps in the 
type system, and make good use of features in code. To the extent we 
can't do what we want to do, the topics you mention are fit.


Andrei