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

As a commercial user (but non contributor) of D, here is my suggestion:
- remove GC and memory management as default
- find all features that are not being maintained or are just top heavy and deprecate.
- find features that should or could be downstream, and deprecate.

Vic
- http://www.quotationspage.com/quote/26979.html


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

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

scope would be nice:)

On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
> Just wondering what the general sentiment is.
>

Multiple alias this (DIP66 / #6083.)

Am 20.12.2014 18:39, schrieb Martin Nowak:
> 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

Shared library support on Windows ;-)

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

D as a language is "feature complete" enough for me as is; improving the compiler, fixing remaining major compiler bugs/inconsistencies between spec and compiler  is more important for me. Maybe the ability to force-inline if nothing else.

Outside the language itself:
- Phobos could obviously use some fixing
  (especially obsolete stuff without a real replacement like std.stream)
- a GC that doesn't suck would help
  (I see people working on that from time to time, never gets finished/integrated)
- A finished std.allocator would help, whether or not Phobos uses it internally
- std.simd
- Proposed changes with GC/RC/manual allocation in would
  be very useful, but I expect that to take a shitload of time,
  assuming it doesn't get derailed and replaced by a yet more grandiose
  idea (remember TempAlloc -> std.allocator -> now this - nothing of that
  got finished)

Also, this pisses me off way too often: a way to build documentation as easily as "doxygen Doxyfile" (no need to write own CSS to get a non-atrocious result, no messing with dependencies because DMD needs to import files I'm not building documentation with, no assuming I have a server by default, no generating files to feed to another program) and get a ready-for-use, readable, static HTML-CSS result. All of DMD/DDoc, ddox and harbored are too involved. (I would also prefer to have Markdown or ReST within DDoc, e.g. I don't find $(B bold) to be readable, I'll probably eventually try to eventually implement that myself).


.. that ended up surprisingly long.
   TLDR: language is good, Phobos needs work, doc generation sucks

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

Unique! and RefCounted! in a usable state.

On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
> Just wondering what the general sentiment is.

I think the main problem is what is there already, which prevents more sensible performance features from being added and also is at odds with ensuring correctness.

By priority:

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

I forgot:

1.5 Explicit inlining and fixing the import system.

On Saturday, 20 December 2014 at 18:42:52 UTC, Vic wrote:
> As a commercial user (but non contributor) of D, here is my suggestion:
> - remove GC and memory management as default

I sure hope not. It would eat a lot of developer time, and then the anti-GC crowd would switch to complaining about the lack of tools even more than they already do. You don't need to change the default in order to allow language users to avoid the GC.