- static foreach (declaration foreach)
- fixing __traits templates (eg getProtection vein extremely flaky, allMembers not working etc) -- seeing as ctfe is one of flagship features of D, it would make sense to actually make it work flawlessly.

On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
> Just wondering what the general sentiment is.
>
> For me it's these 3 points.
>
> - tuple support (DIP32, maybe without pattern matching)
> - working import, protection and visibility rules (DIP22, 313, 314)
> - finishing non-GC memory management

Add scope and properties to that and I think we're in pretty good shape... personally.  Other people will have different pet issues.

-Wyatt

Ola Fosheim Grøstad:

> 1. A well thought out ownership system to replace GC with compiler protocols/mechanisms that makes good static analysis possible and pointers alias free.  It should be designed before "scope" is added and a GC-free runtime should be available.
>
> 2. Redesign features and libraries to better support AVX auto-vectorization as well as explicit AVX programming.
>
> 3. Streamlined syntax.
>
> 4. Fast compiler-generated allocators with pre-initialization for class instancing (get rid off emplace). Profiling based.
>
> 5. Monotonic integers (get rid of modular arithmetics) with range constraints.
>
> 6. Constraints/logic based programming for templates
>
> 7. Either explict virtual or de-virtualizing class functions (whole program optimization).
>
> 8. Clean up the function signatures: ref, in, out, inout and get rid of call-by-name lazy which has been known to be a bug inducing feature since Algol60. There is a reason for why other languages avoid it.
>
> 9. Local precise GC with explicit collection for catching cycles in graph data-structures.
>
> 10. An alternative to try-catch exceptions that enforce error-checking without a performance penalty. E.g. separate error tracking on returns or "transaction style" exceptions (jump to root and free all resources on failure).

This sounds more ambitious than the hypothetical D3 language :-)

Modular arithmetics is handy, when you want it.

I don't understand enough some of your points, so you should popularize better your ideas :-)

Bye,
bearophile

On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
> Just wondering what the general sentiment is.
>
> For me it's these 3 points.
>
> - tuple support (DIP32, maybe without pattern matching)

Nice but not important, unless you mean full tuple redesign (not realistic)

> - working import, protection and visibility rules (DIP22, 313, 314)

MUST HAVE

> - finishing non-GC memory management

a bit hard to define it as a single feature as there are many issues involved

From me:

- do at least something about scope
- make possible to disable attributes (aka !final / !pure)
- better user-defined type support (any built-in type must be possible to emulate via user aggregate)

In general I most commonly don't want to add new features but fix existing ones (in backwards incompatible way) though.

Dicebot:

>> - tuple support (DIP32, maybe without pattern matching)
>
> Nice but not important, unless you mean full tuple redesign (not realistic)

"Full tuples" (without pattern matching) are quite realistic in D. Tuples have a simple uncontroversial semantics and they get used everywhere.

Bye,
bearophile

On Sunday, 21 December 2014 at 09:58:42 UTC, bearophile wrote:
> Dicebot:
>
>>> - tuple support (DIP32, maybe without pattern matching)
>>
>> Nice but not important, unless you mean full tuple redesign (not realistic)
>
> "Full tuples" (without pattern matching) are quite realistic in D. Tuples have a simple uncontroversial semantics and they get used everywhere.

It would require to break existing semantics of template arguments lists and .tupleof and any user code that derives from it to get it clean. This is hardly realistic and anything less (like DIP32) is simply not useful enough.

On 20 Dec 2014 17:45, "Martin Nowak via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> Just wondering what the general sentiment is.
>
> For me it's these 3 points.
>
> - tuple support (DIP32, maybe without pattern matching)
> - working import, protection and visibility rules (DIP22, 313, 314)
> - finishing non-GC memory management

What's missing to make D2 feature complete?

Developers to implement said missing features. :)

On 2014-12-21 10:46, Dicebot wrote:

> - better user-defined type support (any built-in type must be possible
> to emulate via user aggregate)

Any specifics to achieve this?

-- 
/Jacob Carlborg

- Tuple support would be nice (more minor for me)

- Proper @nogc support (Exceptions in particular make @nogc unusable in its current state, I've stopped bothering with it)

- Final -> virtual support (fairly important)

- Fixing importing / visibility (ie, 314 and other issues)


Besides the above already-semi-existing features, I'd really like to see better syntax for creating properties than:

/// Such and such documentation
@property int a() const @safe pure nothrow @nogc {
    return _a;
}
/// Ditto
@property void a(int val) @safe pure nothrow @nogc {
    assert(val > 0);
    this._a = val;
}

Something like the following would be nice (not sure if any language constructs prevent it though): shorter and prevents the awkward glued-together feeling properties have.

/// Such and such documentation
@safe pure nothrow @nogc @property int a {
    const get() { return _a; }
    set(val) {
        assert(val > 0);
        _a = val;
    }
}

Ideally extendable to something like the following for a trivial get/set:

/// Such and such documentation
@safe pure nothrow @nogc @property int a;

On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg wrote:
> On 2014-12-21 10:46, Dicebot wrote:
>
>> - better user-defined type support (any built-in type must be possible
>> to emulate via user aggregate)
>
> Any specifics to achieve this?

Stuff that immediately comes to my mind:

 - some way to define implicit conversion from literals (done at CT)
 - either http://wiki.dlang.org/DIP63 or some other solution to define tuple-like entities
 - solve the issue with impossibility of stripping head const for user-defined container types same as it is down for arrays