On Thursday, 13 November 2014 at 13:29:00 UTC, Wyatt wrote:
> Unfortunately for your sanity, this isn't going to happen.  Similarly unlikely is multiple pointer types, which Walter has repeatedly shot down.  I'd suggest bringing it back up if and when discussion of D3 begins in earnest.

D needs to start to focus on providing an assumption free system level programming language that supports the kind of modelling done for system level programming.

I am not sure if adding templates to D was a good idea, but now that you have gone that route to such a large extent, you might as well do it wholesale with better support for templated SYSTEM programming would make sense. Make it your advantage. (including deforesting/common subexpression substitution, constraints systems etc)

As an application level programming language D stands no chance. More crutches and special casing will not make D a system level programming language. Neither does adding features designed for other languages geared towards functional programming (which is the antithesis of system level programming).

Yes, it can be done using a source to source upgrade tool.

No, attribute inference is not a silver bullet, it means changes to libraries would silently break applications.

Yes, function signatures matters. Function signatures are contracts, they need to be visually clear and the semantics have to be easy to grok.

No, piling up low hanging fruits that are not yet ripe is not a great way to do language design.

On Friday, 14 November 2014 at 14:59:39 UTC, Araq wrote:
>> I think it make sense to have something for ownership. The error of rust wasn't going that road, but going in that road 100%, which come at a cost at interface level which is too important. A simpler ownership system, that fallback on the GC or unsafe feature when it fall short.
>>
>> I'm confident at this point that we can get most of the benefit of an ownership system with something way simpler than rust's system if you accept to not cover 100% of the scenarios.
>
> Do you happen to have any concrete reasons for that? An example
> maybe? Maybe start with explaining how in detail Rust's system is
> too complex? I'm sure the Rust people will be interested in how
> you can simplify a (most likely sound) type system that took
> years to come up with and refine.

I'm not sure we understand rust type system to be too complicated
the same way.

Let's be clear: There is no accidental complexity in Rust's type
system. It is sound and very powerful. There is no way I can
think of you could make it simpler.

That being said, there are cases where Rust's type system shine,
for instance tree like datastructures with same lifetime, passing
down immutable objects to pure functions and so on.

But there are also cases when it become truly infamous like a
digraph of object with disparate lifetime.

Rust made the choice to have this safe memory management that do
not rely on the GC, so they have to handle the infamous cases.
This require a rich and complex type system.

My point is that we can support the nice cases with something
much simpler, while delegating the infamous ones to the GC or
unsafe constructs. The good news is that the nice cases are more
common that the hard ones (or Rust would be absolutely unusable)
so we can reap most of the benefices of a rust like approach
while introducing much less complexity in the language.

 From a cost benefice perspective, this seems like the right way
forward to me.

To quote the guy from the PL for video games video serie, a 85%
solution often is preferable.

On 2014-11-14 15:28, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> I don't know yet, but the 5.1 simulator will probably have to run on
> OS-X 10.6.8 from what I've found on the net. Maybe it is possible to do
> as you said with clang… Hm.

The simulator bundled with Xcode 5 run on Yosemite but not the one bundled with Xcode 4.

-- 
/Jacob Carlborg

On 11/14/2014 4:32 PM, deadalnix wrote:
> To quote the guy from the PL for video games video serie, a 85%
> solution often is preferable.

Spoken like a true engineer!

On 11/13/2014 5:55 AM, Manu via Digitalmars-d wrote:
> I realised within minutes that it's almost impossible to live without slices.
> On the plus side, I've already made lots of converts in my new office
> from my constant ranting :P

You should submit a presentation proposal to the O'Reilly Software Architecture Conference!

  http://softwarearchitecturecon.com/sa2015

On 11/13/2014 3:44 AM, Manu via Digitalmars-d wrote:
> After having adapted to D and distancing from C++, trying to go back
> is like some form of inhuman torture!
> I really don't remember it being as bad as it is... the time away has
> given me new perspective on how terrible C++ is, and I can say with
> confidence, there is NOTHING C++ could do to make itself a 'better
> option' at this point.

What I find odd about the progress of C++ (11, 14, 17, ...) is that there has been no concerted effort to make the preprocesser obsolete.

Am 16.11.2014 um 05:51 schrieb Walter Bright:
> On 11/13/2014 3:44 AM, Manu via Digitalmars-d wrote:
>> After having adapted to D and distancing from C++, trying to go back
>> is like some form of inhuman torture!
>> I really don't remember it being as bad as it is... the time away has
>> given me new perspective on how terrible C++ is, and I can say with
>> confidence, there is NOTHING C++ could do to make itself a 'better
>> option' at this point.
>
> What I find odd about the progress of C++ (11, 14, 17, ...) is that
> there has been no concerted effort to make the preprocesser obsolete.
>

What about templates, compile time reflection, modules and compile time code execution?

No need for the pre-processor other than textual inclusion and conditional compilation.

--
Paulo

On 11/15/2014 11:14 PM, Paulo Pinto wrote:
> Am 16.11.2014 um 05:51 schrieb Walter Bright:
>> What I find odd about the progress of C++ (11, 14, 17, ...) is that
>> there has been no concerted effort to make the preprocesser obsolete.
> What about templates, compile time reflection, modules and compile time code
> execution?

Competent and prominent C++ coding teams still manage to find complex and tangled uses for the preprocessor that rely on the most obscure details of how the preprocessor works, and then hang their whole codebase on it.

I find it baffling, but there it is. I've made some effort to get rid of preprocessor use in the DMD source.


> No need for the pre-processor other than textual inclusion and conditional
> compilation.

Andrei, Herb, and I made a proposal to the C++ committee to introduce 'static if'. It was promptly nailed to the wall and executed by firing squad. :-)

Am 16.11.2014 um 08:44 schrieb Walter Bright:
> On 11/15/2014 11:14 PM, Paulo Pinto wrote:
>> Am 16.11.2014 um 05:51 schrieb Walter Bright:
>>> What I find odd about the progress of C++ (11, 14, 17, ...) is that
>>> there has been no concerted effort to make the preprocesser obsolete.
>> What about templates, compile time reflection, modules and compile
>> time code
>> execution?
>
> Competent and prominent C++ coding teams still manage to find complex
> and tangled uses for the preprocessor that rely on the most obscure
> details of how the preprocessor works, and then hang their whole
> codebase on it.
>
> I find it baffling, but there it is. I've made some effort to get rid of
> preprocessor use in the DMD source.
>
>
>> No need for the pre-processor other than textual inclusion and
>> conditional
>> compilation.
>
> Andrei, Herb, and I made a proposal to the C++ committee to introduce
> 'static if'. It was promptly nailed to the wall and executed by firing
> squad. :-)
>

That was quite bad how it happened.

On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright wrote:
> On 11/14/2014 4:32 PM, deadalnix wrote:
>> To quote the guy from the PL for video games video serie, a 85%
>> solution often is preferable.
>
> Spoken like a true engineer!

More like a consultant for self-help:

http://www.amazon.com/85%25-Solution-Personal-Accountability-Guarantees/dp/0470500166


Real world 85% engineered solutions:

1. Titanic
2. Chernobyl
3. Challenger
4. C++
…