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.

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

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)) ?

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.

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

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.

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.

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.

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.

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.