www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Wishlist for D

reply Ozan <ozan.sueel gmail.com> writes:
Hi

We all have experience with several programming languages and the 
great ideas implemented there. It is close to Xmas and I think 
the right time for wishes about future functions in D. Where is 
right place to put these inspirations on?

Shall we send them directly to the D Foundation presidents? The 
Secretary? A central mailbox?

Regards,  Ozan
Dec 01 2015
next sibling parent reply Suliman <evermind live.ru> writes:
On Tuesday, 1 December 2015 at 16:43:55 UTC, Ozan wrote:
 Hi

 We all have experience with several programming languages and 
 the great ideas implemented there. It is close to Xmas and I 
 think the right time for wishes about future functions in D. 
 Where is right place to put these inspirations on?

 Shall we send them directly to the D Foundation presidents? The 
 Secretary? A central mailbox?

 Regards,  Ozan
Right place is write here
Dec 01 2015
next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Tuesday, 1 December 2015 at 16:48:00 UTC, Suliman wrote:
 Right place is write here
My wishes: - Less flamewars. - A heavy template-based image manipulation library (like antigrain for c++)
Dec 11 2015
next sibling parent ixid <adamsibson hotmail.com> writes:
On Friday, 11 December 2015 at 10:04:22 UTC, Andrea Fontana wrote:
 On Tuesday, 1 December 2015 at 16:48:00 UTC, Suliman wrote:
 Right place is write here
My wishes: - Less flamewars. - A heavy template-based image manipulation library (like antigrain for c++)
As forums go this one is very calm and reasonable. A long thread disagreeing on an issue isn't a flamewar.
Dec 11 2015
prev sibling next sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Friday, 11 December 2015 at 10:04:22 UTC, Andrea Fontana wrote:
 On Tuesday, 1 December 2015 at 16:48:00 UTC, Suliman wrote:
 Right place is write here
My wishes: - Less flamewars. - A heavy template-based image manipulation library (like antigrain for c++)
It's probably not as powerful as antigrain but did you see Vladimir's functional image processing library in AE? Cool stuff. http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
Dec 12 2015
parent reply PuglyWUgly <nospamPls yahoo.com> writes:
D canceled, new language G created for GPU, designed as an array 
processing language. Written in C++ meta templates, otherwise 
nobody will use it. Duh.
Dec 12 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 12 December 2015 at 22:10:25 UTC, PuglyWUgly wrote:
 D canceled, new language G created for GPU, designed as an 
 array processing language. Written in C++ meta templates, 
 otherwise nobody will use it. Duh.
Woah, that's drastic, but sounds cool. Well, if we are going drastic: 1. Get rid of bad typing inherited from C and bad C operator precedence. 2. Debug-mode testing of integer overflow. 3. Proper nominal typing throughout. 4. Strip out less useful features like call by name parameters (lazy) 5. Add a high level IR with advanced static analysis capabilities over it. 6. Clean up the template-system with deductive meta programming. 7. Clean up the syntax, make immutable default, switch to the now pervasive "name:type" convention for adding types to variables. 8. Make memory management a first class compiler based language feature. 9. Make runtime less programming the default, GC/RC optional. 10. Make the default programming model multiple isolated threads with unique_ptr style transfers between them, and add codegen for webbrowsers for it. 11. First class tuple support. 12. Pattern matching. 13. Mandatory handling of return values. 15. Bit specific integer/float type naming: i32, u32, f32, f64 etc. 16. type state / behavioural typing features ...and more...
Dec 12 2015
parent reply Robert burner Schadek <rburners gmail.com> writes:
On Saturday, 12 December 2015 at 22:57:55 UTC, Ola Fosheim 
Grøstad wrote:

 2. Debug-mode testing of integer overflow.
https://github.com/D-Programming-Language/phobos/pull/3389
Dec 13 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 13 December 2015 at 11:18:31 UTC, Robert burner 
Schadek wrote:
 On Saturday, 12 December 2015 at 22:57:55 UTC, Ola Fosheim 
 Grøstad wrote:

 2. Debug-mode testing of integer overflow.
https://github.com/D-Programming-Language/phobos/pull/3389
I know, but that does not help when one are debugging code that doesn't use it.
Dec 13 2015
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 13 December 2015 at 11:25:37 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 13 December 2015 at 11:18:31 UTC, Robert burner 
 Schadek wrote:
 On Saturday, 12 December 2015 at 22:57:55 UTC, Ola Fosheim 
 Grøstad wrote:

 2. Debug-mode testing of integer overflow.
https://github.com/D-Programming-Language/phobos/pull/3389
I know, but that does not help when one are debugging code that doesn't use it.
I have spent a lot of time trying to design the best checked integer type possible for Phobos, and I intend to finish the job (hopefully soon). Nevertheless, I fully agree with Ola: compiler support (similar to how array bounds checking is handled already) would be much better than any library solution could be. Doing it right would also be a fundamental breaking change, though, so this will have to wait for a hypothetical D3.
Dec 14 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 14 December 2015 at 21:27:25 UTC, tsbockman wrote:
 Doing it right would also be a fundamental breaking change, 
 though,
It would require a change away from modular arithmetics as the default, true.
Dec 14 2015
prev sibling parent reply Charles Hixson via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/14/2015 01:27 PM, tsbockman via Digitalmars-d wrote:
 On Sunday, 13 December 2015 at 11:25:37 UTC, Ola Fosheim Grøstad wrote:
 On Sunday, 13 December 2015 at 11:18:31 UTC, Robert burner Schadek 
 wrote:
 On Saturday, 12 December 2015 at 22:57:55 UTC, Ola Fosheim Grøstad 
 wrote:

 2. Debug-mode testing of integer overflow.
https://github.com/D-Programming-Language/phobos/pull/3389
I know, but that does not help when one are debugging code that doesn't use it.
I have spent a lot of time trying to design the best checked integer type possible for Phobos, and I intend to finish the job (hopefully soon). Nevertheless, I fully agree with Ola: compiler support (similar to how array bounds checking is handled already) would be much better than any library solution could be. Doing it right would also be a fundamental breaking change, though, so this will have to wait for a hypothetical D3.
It wouldn't need to be a breaking change if checked integer were a separate type series, as the unsigned series is. The types could be called "cint" etc. I expect that they would incur significant overhead, as I don't think there is hardware support for checked integers, and as such the current types would need to be maintained.
Dec 15 2015
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 16 December 2015 at 07:07:09 UTC, Charles Hixson 
wrote:
 It wouldn't need to be a breaking change if checked integer 
 were a separate type series, as the unsigned series is.  The 
 types could be called "cint" etc.  I expect that they would 
 incur significant overhead, as I don't think there is hardware 
 support for checked integers, and as such the current types 
 would need to be maintained.
There is hardware support for checked integers, actually. Even the library type that Robert Schadek and I have been working on will be able to at least partially leverage that support, through the intrinsics in `core.checkedint`. Still, there is always going to be some runtime overhead associated with checked integers: at a minimum, including a code path to explicitly handle integer math errors increases programs' instruction count significantly. Compiler support would allow the possibility of automatically eliding redundant checks. More importantly, it would also make compilation of code using lots of checked integers much faster, as getting good performance and generic code compatibility with a library checked integer requires templated function calls everywhere, which must all be inlined. As to it being a non-breaking change: the issue is that almost all existing usage of `int`, should really be `cint`. Even if you update your own code to use `cint`, interacting correctly with APIs which erroneously use `int` gets awkward, assuming you want to actually benefit from the improved safety of `cint`. However, updating a public API to use `cint` is a breaking change for both performance and type safety reasons. Any such code updates would also have to be reviewed and tested thoroughly, because while switching to `cint` would *almost* always be a good thing, people do occasionally intentionally make use of the wrapping nature of unchecked integers - and even of the wonkiness of mixed signed/unsigned math. Since there is no standard way currently of marking such cases, only a real person, familiar with the code base, could update it - no (safe) automated updates is possible. Overall, it's probably not worth the additional work and risk of adding support directly to the compiler, unless it's going to become the default (as it should have been from the beginning). Hence, D3...
Dec 15 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 16 December 2015 at 07:41:45 UTC, tsbockman wrote:
 Overall, it's probably not worth the additional work and risk 
 of adding support directly to the compiler, unless it's going 
 to become the default (as it should have been from the 
 beginning). Hence, D3...
Good to see that there is some support for a nextgen version of D. :)
Dec 16 2015
parent reply Yota <yotaxp thatGoogleMailThing.com> writes:
On Wednesday, 16 December 2015 at 12:06:17 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 16 December 2015 at 07:41:45 UTC, tsbockman wrote:
 Overall, it's probably not worth the additional work and risk 
 of adding support directly to the compiler, unless it's going 
 to become the default (as it should have been from the 
 beginning). Hence, D3...
Good to see that there is some support for a nextgen version of D. :)
My biggest wish is to see the design phase of D3 kick off. Ideally, with a big fat label on it saying "Will not be ready for production for at least 5 or 10 years. Your code WILL be broken sooner than later." I feel like D is in a rut with all the best things being shot down because of breaking code. (I understand why we can't break code at this point, but that doesn't make it any less frustrating.) I love almost all of your wishes. =p
Dec 17 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 18 December 2015 at 02:22:48 UTC, Yota wrote:
 My biggest wish is to see the design phase of D3 kick off.  
 Ideally, with a big fat label on it saying "Will not be ready 
 for production for at least 5 or 10 years.  Your code WILL be 
 broken sooner than later."  I feel like D is in a rut with all 
 the best things being shot down because of breaking code. (I 
 understand why we can't break code at this point, but that 
 doesn't make it any less frustrating.)
Exactly.
Dec 18 2015
prev sibling parent rsw0x <anonymous anonymous.com> writes:
On Friday, 18 December 2015 at 02:22:48 UTC, Yota wrote:
 On Wednesday, 16 December 2015 at 12:06:17 UTC, Ola Fosheim 
 Grøstad wrote:
 On Wednesday, 16 December 2015 at 07:41:45 UTC, tsbockman 
 wrote:
 [...]
Good to see that there is some support for a nextgen version of D. :)
My biggest wish is to see the design phase of D3 kick off. Ideally, with a big fat label on it saying "Will not be ready for production for at least 5 or 10 years. Your code WILL be broken sooner than later." I feel like D is in a rut with all the best things being shot down because of breaking code. (I understand why we can't break code at this point, but that doesn't make it any less frustrating.) I love almost all of your wishes. =p
nearly every D release has at least one breaking change already
Dec 18 2015
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 11 December 2015 at 10:04:22 UTC, Andrea Fontana wrote:

 - A heavy template-based image manipulation library (like 
 antigrain for c++)
There is one, it's called ae.utils.graphics and it's awesome. It's a tinier version of antigrain, useful core though.
Dec 13 2015
prev sibling parent ref2401 <refactor24 gmail.com> writes:
On Tuesday, 1 December 2015 at 16:48:00 UTC, Suliman wrote:
 Right place is write here
My wish: New `std.io` package that includes `std.file`, `std.path` and `std.stdio` modules.
Dec 16 2015
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 1 December 2015 at 16:43:55 UTC, Ozan wrote:
 Hi

 We all have experience with several programming languages and 
 the great ideas implemented there. It is close to Xmas and I 
 think the right time for wishes about future functions in D. 
 Where is right place to put these inspirations on?

 Shall we send them directly to the D Foundation presidents? The 
 Secretary? A central mailbox?
Santa Claus 1 Reindeer Street North Pole
 Regards,  Ozan
Or Adam can compile a wish list from a 300+ monster thread ;)
Dec 01 2015
prev sibling next sibling parent BBaz <2b.temp gmx.com> writes:
On Tuesday, 1 December 2015 at 16:43:55 UTC, Ozan wrote:
 Hi

 We all have experience with several programming languages and 
 the great ideas implemented there. It is close to Xmas and I 
 think the right time for wishes about future functions in D. 
 Where is right place to put these inspirations on?

 Shall we send them directly to the D Foundation presidents? The 
 Secretary? A central mailbox?

 Regards,  Ozan
I just wish that the D lang members get that they'll become more and more reviewers...and that they'll accept this role. It shouldn't be so difficult since a slice of them don't code anymore anyway. confere with: http://forum.dlang.org/thread/uxyvbszhtpxobewgnfnq forum.dlang.org ;)
Dec 01 2015
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 1 December 2015 at 16:43:55 UTC, Ozan wrote:
 Hi

 We all have experience with several programming languages and 
 the great ideas implemented there. It is close to Xmas and I 
 think the right time for wishes about future functions in D. 
 Where is right place to put these inspirations on?

 Shall we send them directly to the D Foundation presidents? The 
 Secretary? A central mailbox?

 Regards,  Ozan
If you have very specific ideas rather, you can always create an enhancement request at issues.dlang.org
Dec 01 2015
prev sibling next sibling parent reply Charles Hixson via Digitalmars-d <digitalmars-d puremagic.com> writes:
A "batteries included" extension to phobos modeled after the Python 
modules.
Esp. I'd like a standard linkage to Sqlite via D rather than C, but I'm 
sure that other have other most desired libraries.

Additionally, I'd like fewer language changes.  D is a great language 
now, and changes, while interesting, are (for my purposes) of at best 
dubious value.  (Bug fixes, of course, is a different matter.)

OTOH, I am usually not interested in compile time enhancement, but only 
in execution time enhancements.  E.g., I generally find that using 
ranges is both less intelligible and less flexible than using indexed 
access.  (I originally hoped that foreach would be to allow parallel 
execution, as that was the only use I could see for it. Now I'll 
occasionally use it, but I so often need to iterate over multiple arrays 
that I use indexing much more often.)

On 12/01/2015 08:43 AM, Ozan via Digitalmars-d wrote:
 Hi

 We all have experience with several programming languages and the 
 great ideas implemented there. It is close to Xmas and I think the 
 right time for wishes about future functions in D. Where is right 
 place to put these inspirations on?

 Shall we send them directly to the D Foundation presidents? The 
 Secretary? A central mailbox?

 Regards,  Ozan
Dec 12 2015
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Saturday, 12 December 2015 at 19:55:27 UTC, Charles Hixson 
wrote:
 Now I'll occasionally use it, but I so often need to
 iterate over multiple arrays that I use indexing much more often
Why not use foreach(ref a, ref b, ref c; lockstep(array1, array2, array3)) ?
Dec 12 2015
parent Charles Hixson via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/12/2015 03:47 PM, Jack Stouffer via Digitalmars-d wrote:
 On Saturday, 12 December 2015 at 19:55:27 UTC, Charles Hixson wrote:
 Now I'll occasionally use it, but I so often need to
 iterate over multiple arrays that I use indexing much more often
Why not use foreach(ref a, ref b, ref c; lockstep(array1, array2, array3)) ?
Because indexing is easier, more intelligible, and less error prone.
Dec 12 2015
prev sibling next sibling parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 1 December 2015 at 16:43:55 UTC, Ozan wrote:
 Hi

 We all have experience with several programming languages and 
 the great ideas implemented there. It is close to Xmas and I 
 think the right time for wishes about future functions in D. 
 Where is right place to put these inspirations on?

 Shall we send them directly to the D Foundation presidents? The 
 Secretary? A central mailbox?

 Regards,  Ozan
static foreach standardized low-level optimizations you would find available in something like GNU C - e.g, address of labels(extreme performance benefit can be had when used properly,) likely/unlikely hints for conditionals simd library, or, just an SSE implementation that works across all 3 compilers.
Dec 12 2015
prev sibling parent Jonas Drewsen <nospam4321 hotmail.com> writes:
On Tuesday, 1 December 2015 at 16:43:55 UTC, Ozan wrote:
 Hi

 We all have experience with several programming languages and 
 the great ideas implemented there. It is close to Xmas ....
The one wish I have is to be able to call stuff directly without needing to import the module (like you can in c#): std.stdio.writeln("foo") and not import std.stdio; writeln("foo"); Simple thing - but used regularly enough to be quite annoying not to have. I wonder if there are some kind of parsing/semantic issues with supporting it?
Dec 18 2015