On Sunday, 21 December 2014 at 09:34:33 UTC, bearophile wrote:
> This sounds more ambitious than the hypothetical D3 language :-)

Feature complete should be ambitious! I am only asking for something a little bit better than C++ ;-) I am not asking for fringe features like "multiple alias this"...

> Modular arithmetics is handy, when you want it.

But you always get it… you can just use the modulo-operator.

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

Which points? I assume point 1 was clear, more on point 2 and 3:

On point 2, AVX:

LLVM is getting AVX auto vectorization. AVX uses masks so that you can vectorize loops with conditionals, when the mask goes to zero then the instruction is turned into NOP. So with the proper constructs you can get branch-free vectorized inner loops.

If D wants to stay competitive as a system level language, D need to make sure that programs get efficient AVX auto vectorization out-of-the-box.

I find this poster from the last LLVM meeting interesting:

http://llvm.org/devmtg/2014-10/Slides/Nis-AVX-512ArchPoster.pdf


On point 3, allocators:

If you want reasonable and fast ref counting without code bloat you need to standardize how ref-counting is done. The simple solution is to put the ref count on a negative offset and make sure that all ref-countable class objects are allocated as separate objects.

Then you need a fast allocator. That means you need a pool where alloc/free is O(1) in the common case. By profiling allocation patterns the compiler can generate code that makes objects available when needed. Since most applications have uneven load you can initialize objects to defaults and restructuring the free memory in thread local/global heap when you are having cycles to spare.

If the compiler controls allocations it can also reuse objects when they are dead (by liveness analysis) rather than freeing/allocating, put it on the stack etc…

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

In my mind there are a few categories of outstanding issues.

First, there are cases where the language just does not work as
advertised. Imports are an example of this. Probably scope as
well and maybe shared (although I'm not sure what the situation
with that is).

Second, there are cases where the language works as designed, but
the design makes it difficult to get work done. For example,
@nogc and exceptions, or const with templates (or const
altogether). Order of conditional compilation needs to be defined
(see deadalnix's DIP).

And finally there's the things we would really like for D to be
successful. Tuple support and memory management are examples of
those. This category is essentially infinite.

I really think the first two categories need to be solved before
anything is frozen.

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

There is no "feature complete" language. What makes mainstream languages more likely candidates for future software projects is the fact that they are properly maintained by a team of professionals language community trusts.

I can give Java and C++ as perfect examples. (I am doing this mostly because these two are what I used most of the time in my professional career)
- None of them is "feature complete", yet they are most likely candidate languages for many future software projects. Why? I believe the major reason why is that there is a well-defined standardization process, and what is more important, there are companies behind these languages. Naturally, this makes the new features come to the language *extremely slowly* (we talk 10+ years here).

Perhaps the best course of action is to extract the stable features that D has now, and fork a stable branch that is maintained by people who are actually using that stable version of D in *their products*. This is crucial because it is in their own interest to have this branch as stable as possible.

"Problem" with D is that it is pragmatic language, and this "problem" is why I love D. The reason I say it is a problem is because there are subcommunities and people with their own view on how things "should be". Examples are numerous: GC vs noGC, functional vs OOP, pro- and anti- heavily templated D code. Point is - it is hard to satisfy all.

On Saturday, 20 December 2014 at 20:14:21 UTC, Ola Fosheim
Grøstad wrote:
> 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).

+1000

I will add be consistent into phobos:
- remove all old module as std.mmfile
- put everywere @safe system trusted ...
- use everywhere as possible immutability ( const ref, in,
immutable )
- doing a smaller project with only working and non-deprecated
module
- std.stream
- consistant use of range into phobos

On Saturday, 20 December 2014 at 20:13:31 UTC, weaselcat wrote:
> 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.

+1

No RefCounted classes and non-reentrant GC makes it really awkward to write libraries that handle non-memory resources in a nice way.
My experience with (old versions of) GFM has been horrible at times: you have to close() everything by yourself, if you forget about that sooner or later the GC will collect something, proc a call to close(), which in turns procs a call to the logger, which will end up with a InvalidMemoryOperationError.
Not being able to allocate during ~this() can be extremely annoying for me.

On Monday, 22 December 2014 at 11:03:33 UTC, bioinfornatics wrote:
> - use everywhere as possible immutability ( const ref, in,
> immutable )

Thanks, I forgot that one. Immutable values by default is indeed an important improvement. All by-value parameters to functions should be immutable, period.

- delegates is another type system hole, if it's not going to be fixed, then it should be documented
- members of Object
- evaluate contracts at the caller side
- streams
- reference type AA

On Mon, 22 Dec 2014 11:17:39 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Monday, 22 December 2014 at 11:03:33 UTC, bioinfornatics wrote:
> > - use everywhere as possible immutability ( const ref, in,
> > immutable )
> 
> Thanks, I forgot that one. Immutable values by default is indeed an important improvement. All by-value parameters to functions should be immutable, period.

but why? O_O

On Monday, 22 December 2014 at 21:52:12 UTC, ketmar via Digitalmars-d wrote:
>> Thanks, I forgot that one. Immutable values by default is indeed an important improvement. All by-value parameters to functions should be immutable, period.
>
> but why? O_O

Because it is safer in long functions where you might miss a modification of the input parameter when editing an existing function, and copying from immutable to mutable is free if the parameter is left alone after the copy.

On Mon, 22 Dec 2014 23:25:11 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Monday, 22 December 2014 at 21:52:12 UTC, ketmar via Digitalmars-d wrote:
> >> Thanks, I forgot that one. Immutable values by default is indeed an important improvement. All by-value parameters to functions should be immutable, period.
> >
> > but why? O_O
> 
> Because it is safer in long functions where you might miss a modification of the input parameter when editing an existing function, and copying from immutable to mutable is free if the parameter is left alone after the copy.

i really really hate immutable integer args, for example, and can't see any sense in doing it. that's why i wondered.