On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote:
> I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const.

C++ is locked down in a mine-field of backward compatibility issues and a need to interface with C verbatim (directly including C header files where const parameters might lack the const modifier).

D does not work with C header files and can redefine the interfaces to fit D semantics in C bindings...

On Thursday, 14 July 2016 at 15:59:30 UTC, Ola Fosheim Grøstad wrote:

> It wasn't pure OOP, not sure what you mean by that either.
>
> Not sure what you mean by calling D multi-paradigm.

As opposed to Java that is 100% OOP (well 99%).

>
> I still don't get the comparison. I don't buy a new computer until I am running out of RAM. Speed is no longer a big issue for me, not even with C++ compilation speed.

Ok, this is called a metaphor, a figure of speech. I'll translate it for you:

To wait until a language is perfect, before you deploy it is like constantly waiting for the next generation of computers to come out, before you buy one. I.e. it will never happen, because there will always a next generation that is even better. But, uh, you do get it, don't you?

>> So they don't exist, because the perfect language is also a system level language.
>
> Who has been talking about perfect? Geez, system programming languages are lightyears away from perfect. And they are way way behind high level ones.

And why is that so? Is it because of inherent difficulties to marry low-level functionality with high-level concepts? No, it's because language designers are stooooopid [<= irony]

>> It's tiresome and doesn't get us anywhere.
>
> Then don't argue the point without having a real argument against it.  If your motivation is entirely defensive then you don't really achieve anything.  If your motivation is informational, then it can achieve something. E.g. you could enlighten me.
>
> I don't agree with you that knowledge doesn't get people anywhere. I think it does, it just takes a lot of time, depending on where they come from. I don't know much about Andrei, but Walter does move over time.

Except your knowledge is not focused and thus doesn't help anyone, random rants on whatever topic comes up instead of a focused plan of action with proofs of concept and possibly contributions to the core language. How could anyone keep track of not to mention act on criticism that is scattered out all over threads.

>> E.g. low-level control vs. safety (cf. the discussion about casting away immutable)
>
> I don't think that is a very good argument. All it tells me is that D's approach to safety isn't working and that you need to do this by static analysis over a much simpler core language.

Or is it an intricate problem that's not trivial to solve?

But this is going nowhere ...

On Thursday, 14 July 2016 at 16:47:20 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote:
>> I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const.
>
> C++ is locked down in a mine-field of backward compatibility issues and a need to interface with C verbatim (directly including C header files where const parameters might lack the const modifier).
>
> D does not work with C header files and can redefine the interfaces to fit D semantics in C bindings...

That doesn't explain how you can define the behavior:

    void foo(int const* p) {
        *(const_cast<int*>(p)) = 3;
    }

Does 'p' get modified or is the program going to crash or something else? Please define it for me. C++ says: You can't modify the location pointed to by 'p' from 'p', using const_cast on 'p' you'll either get undefined behavior or it will modify the location 'p' points to. So it is defined to either be undefined or modify the location 'p' refers to. The language isn't able to tell you what will happen so how can it define the behavior?

On Thursday, 14 July 2016 at 17:36:59 UTC, Chris wrote:
> On Thursday, 14 July 2016 at 15:59:30 UTC, Ola Fosheim Grøstad wrote:
>> Not sure what you mean by calling D multi-paradigm.
>
> As opposed to Java that is 100% OOP (well 99%).

Which programming model is it that D supports that Java doesn't?
Functional? Logic? ...?


> Ok, this is called a metaphor, a figure of speech.

Poor metaphor. :)


>But, uh, you do get it, don't you?

That's right, I don't get it, and it isn't true. Walter's vision obviously changed with D2, it was a shift in the core original vision which focused on creating a significantly simpler language than C++.

That's perfectly ok, a change in personal interests towards a more ambitious vision is perfectly ok.  But it has an impact on the outcome, obviously.


> And why is that so? Is it because of inherent difficulties to marry low-level functionality with high-level concepts? No, it's because language designers are stooooopid [<= irony]

Poor irony too... It is so because:

1. system level programming language design has very little academic value

2. it is very difficult to unseat C/C++ which is doing a fair job of it

3. because portability is very very important and difficult

4. because high level languages often try to provide solutions to specific areas


> contributions to the core language. How could anyone keep track of not to mention act on criticism that is scattered out all over threads.

Oh, you don't have to. I am backing those that are arguing for reasonable positions and will do so for as long as I think that will move the project to a more interesting position. Please don't try to make yourself look like a martyr.


> Or is it an intricate problem that's not trivial to solve?

I very seldom run into memory related issues unless I do pointer arithmetic, which @safe does not help with. If it is hard to solve, the solution is easy: postpone it until you have something on paper that can work...

On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote:

> Please don't try to make yourself look like a martyr.

Huh? Where is that coming from all of a sudden? Sorry, I don't see the point of this comment. A martyr for what? Martyrs are stupid people, they should have stayed at home enjoying a nice fresh beer instead of trying to change the course or the world single-handedly. Maybe you should have one too, a beer that is, and think about becoming a contributor to D.

On Thursday, 14 July 2016 at 18:23:54 UTC, Chris wrote:
> On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote:
>
>> Please don't try to make yourself look like a martyr.
>
> Huh? Where is that coming from all of a sudden? Sorry, I don't see the point of this comment.

You were going ad hominem for no good reason. Here is a pretty good rule: if you don't think you will get something out of an discussion, don't engage in it. I personally find that I learn a lot from discussions on language design, even when other people are completely wrong. You have your own view of what is needed, I have a completely different view. You cannot impose your view of what is need on me, it won't work without a good argument to back it up.

My view is that the position that some are arguing holds: the core language has to be stripped down of special casing in order to make major progress.

Aka: one step back, two steps forwards.

If it makes you happy: I am from time to time looking at various ways to modify floating point behaviour, but it won't really matter until complexity is cut back. Because it could easily become another complexity layer on top of what is already there. The best way to improve on D is not to add more complexity, but to cut back to a cleaner core language.

I think you are taking a way too convenient position, somehow pretending that there are no major hurdles to overcome in terms of mindshare. My view is that mindshare is the most dominating problem, e.g. changing viewpoints through arguments is really the only option at the moment.

What other options are there?

On 7/14/16 1:46 PM, Jesse Phillips wrote:
> On Thursday, 14 July 2016 at 16:47:20 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 14 July 2016 at 16:17:19 UTC, Jesse Phillips wrote:
>>> I still haven't found someone who can explain how C++ can define the
>>> behavior of modifying a variable after casting away const.
>>
>> C++ is locked down in a mine-field of backward compatibility issues
>> and a need to interface with C verbatim (directly including C header
>> files where const parameters might lack the const modifier).
>>
>> D does not work with C header files and can redefine the interfaces to
>> fit D semantics in C bindings...
>
> That doesn't explain how you can define the behavior:
>
>     void foo(int const* p) {
>         *(const_cast<int*>(p)) = 3;
>     }
>
> Does 'p' get modified or is the program going to crash or something
> else? Please define it for me. C++ says: You can't modify the location
> pointed to by 'p' from 'p', using const_cast on 'p' you'll either get
> undefined behavior or it will modify the location 'p' points to. So it
> is defined to either be undefined or modify the location 'p' refers to.
> The language isn't able to tell you what will happen so how can it
> define the behavior?

That section means the compiler will stop you from doing it unless you cast it away :)

That is:

*p = 3;

is a compiler error. That's all the note is saying.

What defining the behavior means is that the compiler has to take into account that a variable can change even though all available accesses to it are const.

For example:

int x = 5;
foo(&x);
int y = x;

If what you wrote is UB (as it is in D), then the compiler can go ahead and assign 5 to y.

In C++, the compiler has to reload x, because it may have changed.

Someone explained this to me recently on the NG.

-Steve

On Thursday, 14 July 2016 at 18:36:26 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 14 July 2016 at 18:23:54 UTC, Chris wrote:
>> On Thursday, 14 July 2016 at 18:00:36 UTC, Ola Fosheim Grøstad wrote:
>>
>
> You were going ad hominem for no good reason. Here is a pretty good rule: if you don't think you will get something out of an discussion, don't engage in it. I personally find that I learn a lot from discussions on language design, even when other people are completely wrong. You have your own view of what is needed, I have a completely different view. You cannot impose your view of what is need on me, it won't work without a good argument to back it up.

I certainly don't impose my view on others. The only reason I was going ad hominem was to get you on board in a more substantial manner than engaging in random discussions on the forum.

> My view is that the position that some are arguing holds: the core language has to be stripped down of special casing in order to make major progress.
>
> Aka: one step back, two steps forwards.

D is open source. Would it be possible to provide a stripped down version that satisfies you as a proof of concept? The problem is that abstract reasoning doesn't convince in IT. If you provide something concrete people can work with, then they might pick up on it.

> If it makes you happy: I am from time to time looking at various ways to modify floating point behaviour, but it won't really matter until complexity is cut back. Because it could easily become another complexity layer on top of what is already there. The best way to improve on D is not to add more complexity, but to cut back to a cleaner core language.

That's good to hear. Maybe you should go ahead anyway and see if and how it could be integrated. Maybe it won't add another layer of complexity. Unless you share it, nobody can chip in their 2 cents which might lead to a good solution.

> I think you are taking a way too convenient position, somehow pretending that there are no major hurdles to overcome in terms of mindshare. My view is that mindshare is the most dominating problem, e.g. changing viewpoints through arguments is really the only option at the moment.

You mean you won't give up until everybody has the same opinion as you :) Well, that's not how things work. Maybe a more diplomatic approach would be better.

> What other options are there?

Create facts. Provide a stripped down version of D and show that it's better. You don't need to do it all by yourself. Ask like minded people to help you. I'd be interested in the result. You've praised stripped down D so much that I'm curious. I'm not ideological about things.

On 7/13/2016 4:48 AM, John Colvin wrote:
> Pointer arithmetic in objects is really quite dangerous w.r.t. immutability/const.

Right, and one reason why pointer arithmetic isn't allowed in @safe code.

On 7/14/2016 11:49 AM, Steven Schveighoffer wrote:
> In C++, the compiler has to reload x, because it may have changed.

That's right. I learned that the hard way, when the original optimizer would assume that x hadn't changed. It broke a surprising amount of code.

It also means that the utility of const in C++ is extremely limited.