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

On Wed, 24 Dec 2014 09:32:05 +0000
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. ;-)

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

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.

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.

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

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.

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.

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?

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.