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

Reply via email to