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.
Multiple alias this (DIP66 / #6083.)
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.
Multiple alias this (DIP66 / #6083.)
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.
Multiple alias this (DIP66 / #6083.)
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