Re: What's missing to make D2 feature complete?
On 2014-12-20 23:27:18 +, 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 +10. 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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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 :(
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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?
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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?
Re: What's missing to make D2 feature complete?
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?
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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?
Re: What's missing to make D2 feature complete?
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...
Re: What's missing to make D2 feature complete?
Ola Fosheim Grøstad wrote in message news:cfqevmhbwagvbqvgd...@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.
Re: What's missing to make D2 feature complete?
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 n0 ? x : 0; // modified from return x
}
Re: What's missing to make D2 feature complete?
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 n0 ? 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.
Re: What's missing to make D2 feature complete?
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 n0 ? 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.
Re: What's missing to make D2 feature complete?
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);
...
}
Re: What's missing to make D2 feature complete?
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 n0 ? 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.
Re: What's missing to make D2 feature complete?
Ola Fosheim Grøstad wrote in message
news:ggcloheiypsxdssfv...@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 n0 ? 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.
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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...
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
On Wed, 24 Dec 2014 09:32:05 +
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`,
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);
...
}
void myFunc(T) (T numm) if (isIntegral!numm) {
static if (isMutable!numm) alias num = numm;
else auto num = cast(Unqual!T)numm;
...
}
heh. catched a bug in my code with immutable ints recently, wrote the
quoted snippet. ;-)
signature.asc
Description: PGP signature
Re: What's missing to make D2 feature complete?
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...)
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
On Tue, 23 Dec 2014 08:26:15 + via Digitalmars-d digitalmars-d@puremagic.com wrote: 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. 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. signature.asc Description: PGP signature
Re: What's missing to make D2 feature complete?
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...)
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
Ola Fosheim Grøstad wrote in message news:gkhgxlioxkzmxbiaz...@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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
- 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
Re: What's missing to make D2 feature complete?
On Mon, 22 Dec 2014 11:17:39 + via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 22 December 2014 at 11:03:33 UTC, bioinfornatics wrote: - use everywhere as possible immutability ( const ref, in, immutable ) Thanks, I forgot that one. Immutable values by default is indeed an important improvement. All by-value parameters to functions should be immutable, period. but why? O_O signature.asc Description: PGP signature
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
On Mon, 22 Dec 2014 23:25:11 + via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 22 December 2014 at 21:52:12 UTC, ketmar via Digitalmars-d wrote: Thanks, I forgot that one. Immutable values by default is indeed an important improvement. All by-value parameters to functions should be immutable, period. but why? O_O Because it is safer in long functions where you might miss a modification of the input parameter when editing an existing function, and copying from immutable to mutable is free if the parameter is left alone after the copy. i really really hate immutable integer args, for example, and can't see any sense in doing it. that's why i wondered. signature.asc Description: PGP signature
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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. :)
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
- 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;
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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…
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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:)
Re: What's missing to make D2 feature complete?
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.)
Re: What's missing to make D2 feature complete?
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 ;-)
Re: What's missing to make D2 feature complete?
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
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
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).
Re: What's missing to make D2 feature complete?
I forgot: 1.5 Explicit inlining and fixing the import system.
Re: What's missing to make D2 feature complete?
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.
Re: What's missing to make D2 feature complete?
- 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.
Re: What's missing to make D2 feature complete?
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
