www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's missing to make D2 feature complete?

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
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
Dec 20 2014
next sibling parent reply "Vic" <vic apakau.com> writes:
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
Dec 20 2014
next sibling parent reply "bachmeier" <no spam.net> writes:
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.
Dec 20 2014
parent reply "aldanor" <i.s.smirnov gmail.com> writes:
- 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.
Dec 20 2014
parent Shammah Chancellor <anonymous coward.com> writes:
On 2014-12-20 23:27:18 +0000, aldanor said:


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


This +100000.

I use this stuff in all my D projects since I learned how to do it, and 
it's extremely useful -- but very clunky.

-S.
Jan 08 2015
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Saturday, 20 December 2014 at 18:42:52 UTC, Vic wrote:

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


Any particular suggestions?
Dec 25 2014
prev sibling next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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:)
Dec 20 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/20/14 10:45 AM, Jonathan Marler 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


 scope would be nice:)


That would be part of non-GC. -- Andrei
Dec 23 2014
prev sibling next sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:

 Just wondering what the general sentiment is.
Dec 20 2014
parent reply "Martin Nowak" <code dawg.eu> writes:
On Saturday, 20 December 2014 at 19:22:05 UTC, safety0ff wrote:

 On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak 
 wrote:

 Just wondering what the general sentiment is.





It's already in :), at least the DIP just got approved.
Would it really have been a dealbreaker?
Dec 25 2014
parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Thursday, 25 December 2014 at 09:46:19 UTC, Martin Nowak wrote:

 On Saturday, 20 December 2014 at 19:22:05 UTC, safety0ff wrote:

 On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak 
 wrote:

 Just wondering what the general sentiment is.





 It's already in :), at least the DIP just got approved.
 Would it really have been a dealbreaker?


Late reply:

No, not a dealbreaker (at least for any of the code I've 
written,) I was focusing on objectively missing features rather 
than sentiments :)

That being said, multiple alias this should considerably expand 
the implicit conversion and composition options in D.
Jan 08 2015
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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 ;-)
Dec 20 2014
parent reply "Martin Nowak" <code dawg.eu> writes:
On Saturday, 20 December 2014 at 19:51:18 UTC, Benjamin Thaut 
wrote:

 Am 20.12.2014 18:39, schrieb Martin Nowak:
 Shared library support on Windows ;-)


That's not really a language thing, but indeed important.
Dec 25 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-12-25 10:11, Martin Nowak wrote:


 That's not really a language thing, but indeed important.


Add OS X to that.

-- 
/Jacob Carlborg
Dec 27 2014
prev sibling next sibling parent "Kiith-Sa" <kiithsacmp gmail.com> writes:
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
Dec 20 2014
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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.
Dec 20 2014
parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
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.
Dec 22 2014
parent "Martin Nowak" <code dawg.eu> writes:
On Monday, 22 December 2014 at 11:06:13 UTC, Francesco Cattoglio 
wrote:

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


Can't you combine RefCounted with Scoped?


 Not being able to allocate during ~this() can be extremely 
 annoying for me.


It's a bug (limitation), eventually it will get fixed.
Dec 25 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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).
Dec 20 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
I forgot:

1.5 Explicit inlining and fixing the import system.
Dec 20 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Dec 21 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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…
Dec 21 2014
prev sibling next sibling parent reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
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
Dec 22 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Dec 22 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 )


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


but why? O_O
Dec 22 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Dec 22 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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=20
 Digitalmars-d wrote:

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


 but why? O_O


=20
 Because it is safer in long functions where you might miss a=20
 modification of the input parameter when editing an existing=20
 function, and copying from immutable to mutable is free if the=20
 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.
Dec 22 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via 
Digitalmars-d wrote:

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


It might be a bit annoying for short functions, but in principle 
the function signature should be written for the user (document 
an encapsulated interface) and exposing irrelevant aspects of the 
implementation in the interface is "bad taste".
Dec 23 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 23 Dec 2014 08:26:15 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via=20
 Digitalmars-d wrote:

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


=20
 It might be a bit annoying for short functions, but in principle=20
 the function signature should be written for the user (document=20
 an encapsulated interface) and exposing irrelevant aspects of the=20
 implementation in the interface is "bad taste".


that's why we have `in` keyword, which clearly indicates that argument
is "in only". making `in` default is breaking of my lovely principle of
least astonishment.
Dec 23 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 December 2014 at 08:43:06 UTC, ketmar via 
Digitalmars-d wrote:

 that's why we have `in` keyword, which clearly indicates that 
 argument
 is "in only". making `in` default is breaking of my lovely 
 principle of
 least astonishment.


"in" is "const scope"... But signatures in D are too noisy. It is 
very difficult to avoid, so it is important to keep signatures 
simple for increased legibility.

I think "in", "out", "inout" and "scope "should go. Make all 
parameters that are by-value immutable by default. Make all 
parameters that are ref scope restricted and alias free by 
default. Add tuples. Add ways to express that parameters are used 
in dangerous ways ("escapable", "returnable"...)
Dec 23 2014
next sibling parent "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
 I think "in", "out", "inout" and "scope "should go. Make all 
 parameters that are by-value immutable by default.


I agree with this. In more that could to be interesting if
compiler could translate "in"  to something like "const scope
ref"  when it is an array or heavy object. to save memory
allocation and ease the way to get some better performance.
Dec 23 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 23 December 2014 at 09:29:20 UTC, Ola Fosheim Grøstad 
wrote:

 parameters that are ref scope restricted and alias free by 
 default. Add tuples. Add ways to express that parameters are


Actually, "alias free" by default might be a bit too much, maybe 
just add "restricted" and a mechanism where the compiler presents 
a warning if optimization was limited by not having a guarantee. 
Then the implementor can add restricted where it is needed to get 
better performance.
Dec 23 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ola Fosheim Grøstad" " wrote in message 
news:gkhgxlioxkzmxbiazfwn forum.dlang.org...


 On Tuesday, 23 December 2014 at 01:42:49 UTC, ketmar via Digitalmars-d 
 wrote:

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


 It might be a bit annoying for short functions, but in principle the 
 function signature should be written for the user (document an 
 encapsulated interface) and exposing irrelevant aspects of the 
 implementation in the interface is "bad taste".


Making value parameters immutable, and therefore making the fact that 
they're not modified inside the function visible externally, _IS_ "exposing 
irrelevant aspects of the implementation in the interface".  The caller 
doesn't care what you do with them.
Dec 23 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 07:44:21 UTC, Daniel Murphy 
wrote:

 Making value parameters immutable, and therefore making the 
 fact that they're not modified inside the function visible 
 externally, _IS_ "exposing irrelevant aspects of the 
 implementation in the interface".  The caller doesn't care what 
 you do with them.


No. Make value parameters immutable, period. No mutable version 
as an option. This does not expose anything to the caller.

If you want a mutable version in the implementation, do so in the 
function body. If you only refer the mutable version in the 
function body then the overhead will be optimized away by the 
backend.
Dec 23 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ola Fosheim Grøstad" " wrote in message 
news:cfqevmhbwagvbqvgdlsd forum.dlang.org...


 No. Make value parameters immutable, period. No mutable version as an 
 option. This does not expose anything to the caller.


The same reasoning applies to making all value parameters mutable.
Dec 24 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 08:22:46 UTC, Daniel Murphy 
wrote:

 The same reasoning applies to making all value parameters 
 mutable.


Yes, but my point was that making all value parameters mutable is 
at odds with correctness when you later edit it since you no 
longer know whether it has been modified or not.

E.g.

int myfunc(int n){
     ...lotsofstuff...
     x = mayormaynotchange(n);
    ...lotsofstuff...
    return n>0 ? x : 0;  // modified from "return x"
}
Dec 24 2014
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 24 December 2014 at 08:39:26 UTC, Ola Fosheim 
Grøstad wrote:

 int myfunc(int n){
     ...lotsofstuff...
     x = mayormaynotchange(n);
    ...lotsofstuff...
    return n>0 ? x : 0;  // modified from "return x"
 }


If you require another variable for a sanitized version of `n`, 
you get confused, when to use `n` and when to use `x`, they are 
almost the same and if you pick a wrong value, the code will 
break sometimes.
Dec 24 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 09:02:56 UTC, Kagamin wrote:

 On Wednesday, 24 December 2014 at 08:39:26 UTC, Ola Fosheim 
 Grøstad wrote:

 int myfunc(int n){
    ...lotsofstuff...
    x = mayormaynotchange(n);
   ...lotsofstuff...
   return n>0 ? x : 0;  // modified from "return x"
 }


 If you require another variable for a sanitized version of `n`, 
 you get confused, when to use `n` and when to use `x`, they are 
 almost the same and if you pick a wrong value, the code will 
 break sometimes.


Not really, because you should strive to keep mutable state 
local. Validation does not belong to the implementation, so "the 
right way" is to put it in a wrapper before you call the function 
that does the actual work.

When functions get long and complicated and evolve over time then 
all mutable state become a source for errors.

I never want to change parameter values for long functions. I do 
it for because I am in a hurry. The more constraint the language 
impose the better code I am likely to write.
Dec 24 2014
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 24 December 2014 at 09:18:43 UTC, Ola Fosheim 
Grøstad wrote:

 Not really, because you should strive to keep mutable state 
 local.


Even if it's local, there are still many similar values to see:
return n>0 ? x : 0;


 Validation does not belong to the implementation, so "the right 
 way" is to put it in a wrapper before you call the function 
 that does the actual work.


Unlikely to be done. Sanitization is usually done in place.


 When functions get long and complicated and evolve over time 
 then all mutable state become a source for errors.


Just wanted to say immutability doesn't look that fool-proof.
Dec 24 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 09:46:11 UTC, Kagamin wrote:

 On Wednesday, 24 December 2014 at 09:18:43 UTC, Ola Fosheim 
 Grøstad wrote:

 Validation does not belong to the implementation, so "the 
 right way" is to put it in a wrapper before you call the 
 function that does the actual work.


 Unlikely to be done. Sanitization is usually done in place.


You could improve this by having "parameterless light weight 
lambdas":

immutable i = { ...mutable computation...; return x+n; }

Doing things "in place" is kind of pointless if the SSA form in 
the back-end turns it into immutable anyway. If it is done 
"proper in place" you no longer have a value type, but a 
reference type...
Dec 24 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 09:02:56 UTC, Kagamin wrote:

 If you require another variable for a sanitized version of `n`, 
 you get confused, when to use `n` and when to use `x`, they are


Btw, this is case where preventing shadowing becomes an issue, as 
you could have solved this easily using immutable shadowing:

func(immutable int n){
     trustmeiwantoshadowthis immutable n = sanitize(n);
    ...
}
Dec 24 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 24 Dec 2014 09:32:05 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Wednesday, 24 December 2014 at 09:02:56 UTC, Kagamin wrote:

 If you require another variable for a sanitized version of `n`,=20
 you get confused, when to use `n` and when to use `x`, they are


=20
 Btw, this is case where preventing shadowing becomes an issue, as=20
 you could have solved this easily using immutable shadowing:
=20
 func(immutable int n){
      trustmeiwantoshadowthis immutable n =3D sanitize(n);
     ...
 }


  void myFunc(T) (T numm) if (isIntegral!numm) {
    static if (isMutable!numm) alias num =3D numm;
    else auto num =3D cast(Unqual!T)numm;
    ...
  }

heh. catched a bug in my code with immutable ints recently, wrote the
quoted snippet. ;-)
Dec 24 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ola Fosheim Grøstad" " wrote in message 
news:ggcloheiypsxdssfvwav forum.dlang.org...


 Yes, but my point was that making all value parameters mutable is at odds 
 with correctness when you later edit it since you no longer know whether 
 it has been modified or not.


Modifying parameters usually falls into one of three classes: (in my code at 
least)
1. 'fixing' the value (eg removing invalid characters from a string, 
rounding)
2. reusing the variable
3. consuming the variable (eg popFront on a range)

3 can't be const/immutable, 2 should probably use different variables, but I 
don't have a problem with 1 being mutable.


 E.g.

 int myfunc(int n){
      ...lotsofstuff...
      x = mayormaynotchange(n);
     ...lotsofstuff...
     return n>0 ? x : 0;  // modified from "return x"
 }


I see this as more of an argument for avoiding long functions.  Marking 
every possible parameter as const/immutable has a cost, and I don't think 
the number of bugs it prevents justifies it.  If it was the default the cost 
wouldn't exist.
Dec 24 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 10:32:33 UTC, Daniel Murphy 
wrote:

 I see this as more of an argument for avoiding long functions.  
 Marking every possible parameter as const/immutable has a cost, 
 and I don't think the number of bugs it prevents justifies it.  
 If it was the default the cost wouldn't exist.


I want immutable by default, everywhere... Yes.

A lot of the semantics of current programming languages is due to 
bad habits that was caused by languages designed for less capable 
backends. When those languages were designed you had to optimize 
trivial code by hand. C  falls into this category.
Dec 24 2014
parent reply "eles" <eles eles.com> writes:
On Wednesday, 24 December 2014 at 11:24:26 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 24 December 2014 at 10:32:33 UTC, Daniel Murphy 
 wrote:



 I want immutable by default, everywhere... Yes.


"sanity by default" should be the mantra. well, read "safety" 
instead of "sanity"...

I like the concept of a "safe C++, but with the same power". Yes, 
we talk about D here and D is more than that. But let's not 
neglect this.

C++ is important. Go expected C++ programmers to come, they 
received only python & co. programmers. People form the C++ world 
need something better. But they won't trade C++ for anything less 
than C++, even if the niche where D would fall behind C++ would 
be very narrow. In this case, even "very" == "too little".
Dec 24 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 13:10:58 UTC, eles wrote:

 C++ is important. Go expected C++ programmers to come, they 
 received only python & co. programmers. People form the C++ 
 world need something better. But they won't trade C++ for 
 anything less than C++, even if the niche where D would fall 
 behind C++ would be very narrow. In this case, even "very" == 
 "too little".


Yes, I agree. I think it is likely that a future version of Rust 
with a little more streamlined syntax will take over for C++ 
unless some other language start to focus on C++ parity. And we 
are not talking yesterdays C++, but next gen x86 C++. That means 
4000 intrinsics, auto-vectorization and possibly whole program 
optimization...

But Go is a strong contender in the non-interactive/non-realtime 
space where people used to write programs in C/C++, but hardware 
has improved enough to not warrant bleeding edge performance. 
(Suitable for web server, not suitable for DSP...)
Dec 24 2014
parent reply "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Wednesday, 24 December 2014 at 16:10:05 UTC, Ola Fosheim
Grøstad wrote:

 And we are not talking yesterdays C++, but next gen x86 C++. 
 That means 4000 intrinsics, auto-vectorization and possibly 
 whole program optimization...


Do you propose any changes to the language syntax for
auto-vectorization and whole program optimization ? As far as I
can see, those are compiler features, they are not related to the
language syntax/semantics at all.
Dec 24 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 17:46:39 UTC, Matthias Bentrup 
wrote:

 Do you propose any changes to the language syntax for
 auto-vectorization and whole program optimization ?


You mean semantics.


 As far as I
 can see, those are compiler features, they are not related to 
 the language syntax/semantics at all.


How you structure an array of structs affects performance. What 
you do in loops affects ability to auto vectorize. How will the 
compiler know how to lay out arrays of structs if you don't have 
whole program optimization? How can you be maximize the ability 
to vectorize processing if you don't deliberately design for it? 
It affects language design, library design and application 
architecture.
Dec 24 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 24 December 2014 at 19:59:31 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 24 December 2014 at 17:46:39 UTC, Matthias 
 Bentrup wrote:

 Do you propose any changes to the language syntax for
 auto-vectorization and whole program optimization ?


 You mean semantics.


 As far as I
 can see, those are compiler features, they are not related to 
 the language syntax/semantics at all.


 How you structure an array of structs affects performance. What 
 you do in loops affects ability to auto vectorize. How will the 
 compiler know how to lay out arrays of structs if you don't 
 have whole program optimization? How can you be maximize the 
 ability to vectorize processing if you don't deliberately 
 design for it? It affects language design, library design and 
 application architecture.


Languages like Chapel and X10 are already better candidates in 
the HPC community, unless D inherits the same features.

--
Paulo
Dec 24 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 24 December 2014 at 21:01:11 UTC, Paulo Pinto wrote:

 Languages like Chapel and X10 are already better candidates in 
 the HPC community, unless D inherits the same features.


SIMD is important for all applications that want speed, not only 
HPC. Being compatible with C is important, but D has locked 
itself too closely to C semantics which are "going out of 
fashion" on the hardware side. You can have automatic, 
semi-automatic or manual SIMD support, but you need to make sure 
that you get the right layout if you want good speed. That makes 
it a language/standard library design consideration.
Dec 24 2014
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Saturday, 20 December 2014 at 20:14:21 UTC, Ola Fosheim 
Grøstad wrote:

 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.


If you have any concrete ideas here, now is the right time to 
talk with Walter.
You might want to respond to 
http://forum.dlang.org/post/m5p99m$luk$1 digitalmars.com or open 
a new thread that mentions DIP69 in it's title.


 2. Redesign features and libraries to better support AVX 
 auto-vectorization as well as explicit AVX programming.


I wanted to put that on my list too, as cross-compiler SIMD 
support.
Are there any issues with dmd's approach to SIMD intrinsics and 
why didn't GDC and LDC follow?
Dec 25 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 25 December 2014 at 10:39:13 UTC, Martin Nowak wrote:

 You might want to respond to 
 http://forum.dlang.org/post/m5p99m$luk$1 digitalmars.com or 
 open a new thread that mentions DIP69 in it's title.


I have responded in the thread.  I think ownership has to be 
worked out first... and that will take time to get right if you 
want something better than c++.


 I wanted to put that on my list too, as cross-compiler SIMD 
 support.


Not sure if ARM Neon can support writemasks and zeromasks 
efficiently...
Dec 25 2014
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Dec 20 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Dec 21 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Dec 21 2014
parent "Dicebot" <public dicebot.lv> writes:
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.
Dec 21 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 21 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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
Dec 21 2014
parent reply "Martin Nowak" <code dawg.eu> writes:
On Sunday, 21 December 2014 at 12:48:42 UTC, Dicebot wrote:

 On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg 
 wrote:

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


 Stuff that immediately comes to my mind:

  - some way to define implicit conversion from literals (done 
 at CT)


Any ideas on that? It's an outstanding problem for the library AA 
work.


  - solve the issue with impossibility of stripping head const 
 for user-defined container types same as it is down for arrays


Yeah, that's as annoying as the ConstRange thingie.
We hit both issues when working on Array.
https://github.com/D-Programming-Language/phobos/pull/2631#issuecomment-61255792
Would be great to formalize the language deficiencies and 
prescribe some treatment.
Dec 25 2014
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 25 December 2014 at 10:06:35 UTC, Martin Nowak wrote:

 On Sunday, 21 December 2014 at 12:48:42 UTC, Dicebot wrote:

 On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg 
 wrote:

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


 Stuff that immediately comes to my mind:

 - some way to define implicit conversion from literals (done 
 at CT)


 Any ideas on that? It's an outstanding problem for the library 
 AA work.


No, sadly no right now - it is not a pressing issue for things I 
need right now so I avoid investing too much thinking into 
finding sound solution, sorry :(
Dec 29 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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. :)
Dec 21 2014
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
- 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;
Dec 21 2014
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Dec 22 2014
parent "Martin Nowak" <code dawg.eu> writes:
On Monday, 22 December 2014 at 09:05:03 UTC, Peter Alexander 
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


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

 maybe shared although I'm not sure what the situation
 with that is


Noone knows, that's the problem ;).


 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.


It rather appears to be small.
Keeping the horizon near, helps to focus on the outstanding 
implementation issues.
Dec 25 2014
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
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.
Dec 22 2014
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
- 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
Dec 22 2014
parent reply "Martin Nowak" <code dawg.eu> writes:
On Monday, 22 December 2014 at 11:55:36 UTC, Kagamin wrote:

 - delegates is another type system hole, if it's not going to 
 be fixed, then it should be documented


We did fix a few things there, are the rest filed in Bugzilla?


 - members of Object


???


 - evaluate contracts at the caller side
 - streams
 - reference type AA


What do you mean by that?
Dec 25 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-12-25 10:29, Martin Nowak wrote:

 On Monday, 22 December 2014 at 11:55:36 UTC, Kagamin wrote:

 - delegates is another type system hole, if it's not going to be
 fixed, then it should be documented


 We did fix a few things there, are the rest filed in Bugzilla?


 - members of Object


 ???


There has been some talk about remove all methods in Object and make 
them free functions. Perhaps that's what's being referred.

-- 
/Jacob Carlborg
Dec 27 2014
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-Dec-2014 20:39, 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


- final decision on  property

-- 
Dmitry Olshansky
Dec 23 2014
parent "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 23 December 2014 at 17:34:29 UTC, Dmitry Olshansky 
wrote:

 - final decision on  property


That one is easy, there is already a semi-offical decision.
http://wiki.dlang.org/DIP23
Dec 25 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/20/14 9:39 AM, 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


Great idea to start a list! Shared semantics and improving 
multithreading also come to mind. -- Andrei
Dec 23 2014
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 24 December 2014 at 02:38:02 UTC, Andrei 
Alexandrescu wrote:

 On 12/20/14 9:39 AM, Martin Nowak wrote:

 Shared semantics and improving multithreading also come to 
 mind. -- Andrei


O God! +1000 ;-P

---
PAOLO
Dec 24 2014
parent "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 24 December 2014 at 10:35:46 UTC, Paolo Invernizzi 
wrote:

 On Wednesday, 24 December 2014 at 02:38:02 UTC, Andrei 
 Alexandrescu wrote:

 On 12/20/14 9:39 AM, Martin Nowak wrote:

 Shared semantics and improving multithreading also come to 
 mind. -- Andrei


 O God! +1000 ;-P


True, a DIP on shared would help. There is TDPL's understanding 
of shared to start with.
Dec 25 2014