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

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

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.

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

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.

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

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?