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 


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