D parsing

[deadalnix]

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.

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