On Friday, 15 July 2016 at 23:00:45 UTC, Walter Bright wrote:
> On 7/15/2016 1:48 PM, Shachar Shemesh wrote:
>> On 15/07/16 22:50, Walter Bright wrote:
>>
>>> You can do logical const in D just like in C++, and get those
>>> performance gains. You just can't call it "const". But you can call it
>>> /*logical_const*/ and get the same result.
>>
>> No, you can't. The fact that the compiler enforces the no const to mutable
>> transition (unless you use a cast)
>
> The compiler does next to nothing - the maintainer can stick in 'mutable' members, and there's no reliable way to detect that. The maintainer can stick in const removing casts, and there's no reliable way to detect that, either.
>
> If it's not mechanically checkable, it is not reliable, and is what I call "faith-based programming."
>
>
>> is one of the main appeals of using const in
>> any language. If you call something "logical const", but the compiler does not
>> help you to catch bugs, then I don't see the point.
>
> I agree, and the C++ compiler is unable to verify "logical const". It's entirely based on faith.
>
>
>> In effect, if logical const is what you want, C++ gives you a tool while D
>> leaves you to your own devices. As a result, a lot of places you'd define as
>> const in C++ are defined mutable in D, losing language expressiveness.
>
> You and I certainly have polar opposite opinions on that. C++ does not have a notion of "logical const" (it is not in the C++ Standard). It's an uncheckable convention, might as well just use /*logical const*/.
>
> D, on the other hand, has verifiable const and verifiable purity.

D's const/immutable feature is powerful and I love it. I would not trade it for C++'s version of const. It also seems fair to say that const as C++ implements it, would not be worth adding to D even if having two very similar features wasn't confusing. After all, every feature starts with a negative score.

This subthread took it too far, that's the only reason I waded in. C++'s const feature is not entirely useless.

Similarly:
> If it's not mechanically checkable, it is not reliable,

I agree and I like mechanically checkable things. But I also like compiler features that mix mechanical checking with the ability to attest to something that can't be mechanically checked. Like the @system attribute. So this line of reasoning feels incomplete to me. Are we talking here about immutable/const only within the context of @safe code? If so, then I missed that but I get it. Otherwise, I don't get it.

On 7/15/2016 8:25 PM, Andrew Godfrey wrote:
> I agree and I like mechanically checkable things. But I also like compiler
> features that mix mechanical checking with the ability to attest to something
> that can't be mechanically checked. Like the @system attribute. So this line of
> reasoning feels incomplete to me. Are we talking here about immutable/const only
> within the context of @safe code? If so, then I missed that but I get it.

Since casting away immutable/const is allowed in @system code, yes, I am referring to @safe code here.

On Saturday, 16 July 2016 at 04:24:39 UTC, Walter Bright wrote:
> On 7/15/2016 8:25 PM, Andrew Godfrey wrote:
>> I agree and I like mechanically checkable things. But I also like compiler
>> features that mix mechanical checking with the ability to attest to something
>> that can't be mechanically checked. Like the @system attribute. So this line of
>> reasoning feels incomplete to me. Are we talking here about immutable/const only
>> within the context of @safe code? If so, then I missed that but I get it.
>
> Since casting away immutable/const is allowed in @system code, yes, I am referring to @safe code here.

Ok. Well, when you and Shachar were arguing, it still doesn't seem like Shachar was talking about @safe code specifically. I can't wrap my mind around wanting a "logical const" feature usable in @safe context; you could already use @system for those cases.

On 16/07/16 07:24, Walter Bright wrote:
>
> Since casting away immutable/const is allowed in @system code, yes, I am
> referring to @safe code here.
>

That is something without which none of your arguments made sense to me. Thank you for your clarification.

So, would you say you shouldn't use D unless all of your code is @safe? Most? Some? None?

Shachar

On 16/07/16 02:04, Walter Bright wrote:
> On 7/15/2016 1:58 PM, Shachar Shemesh wrote:
>> Do enlighten me how to use intrusive reference counting in D. I am quite
>> interested in the answer.
>
> Andrei and I are working on it. As he's expressed elsewhere, the idea is
> to maintain the reference count in memory that is outside the type
> system. It's meant to work hand-in-glove with the storage allocator.
>

First of all, it sounds like you envision that everyone will solely be using the D supplied allocators, and no one will be writing their own. That's not my vision of how a system programming language is used. In fact, I have seen very few large scale projects where a custom allocator was not used.

Either way, prefixing data to a structure is not what "intrusive" means.

But even if this turns out to be an adequate replacement for all the cases in which I'd want to use intrusive reference counting in C++ (unlikely), that only works for my first example, not my second one.

Shachar

On Friday, 15 July 2016 at 09:29:27 UTC, Kagamin wrote:
> On Thursday, 14 July 2016 at 20:12:13 UTC, Ola Fosheim Grøstad wrote:
>> And please note that this horrible excuse is propagate in the C++ community too. Time and time again people claim that C++ is complex, but it has to be like that in order to provide the features it provides.
>>
>> Not true for C++.
>>
>> Not true for D.
>
> Your suggestion for static analysis goes the same way: static analysis is way more complex than D currently is, but you suggest it must be this complex?

Not sure what you mean.

1. It is more time consuming to write an analysis engine that can cover convoluted machinery than simple machinery.

2. It it more difficult to extend complex machinery than simple machinery.

3. It is more work to figure out adequate simple machinery to describe complex machinery, than just keeping things simple from the start.

Not very surprising that experienced language designers try to keep the core language as simple as possible?

On 7/15/2016 11:04 PM, Andrew Godfrey wrote:
> Ok. Well, when you and Shachar were arguing, it still doesn't seem like Shachar
> was talking about @safe code specifically. I can't wrap my mind around wanting a
> "logical const" feature usable in @safe context; you could already use @system
> for those cases.

@system provides a way around the type system, and offers fewer guarantees, sort of "use at your own risk". But use of @system is checkable, and when used properly only a small percentage of the code should be in @system functions.

But in C++, everything is @system. I'm not sure how people successfully create enormous programs with it. I do know that the makers of add-on checkers like Coverty make bank. I once told a Coverity salesman that the purpose of D was to put Coverity (and its competitors) out of business :-) I saw him again a couple years later and he remembered me and that line!

On 7/15/2016 11:12 PM, Shachar Shemesh wrote:
> So, would you say you shouldn't use D unless all of your code is @safe? Most?
> Some? None?

The idea is to minimize the use of @system.

If you've got a large team and large codebase, the use of @system should merit special attention in code reviews, and should be in the purview of the more experienced programmers.

There's way too much @system in Phobos, and I expect most of it can be scrubbed out.

On 7/15/2016 11:28 PM, Shachar Shemesh wrote:
> First of all, it sounds like you envision that everyone will solely be using the
> D supplied allocators, and no one will be writing their own.

There won't be anything stopping anyone from writing their own allocators, just like there's nothing stopping one from writing their own sine and cosine functions. I'm well aware that systems programmers like to write their own allocators.


> But even if this turns out to be an adequate replacement for all the cases in
> which I'd want to use intrusive reference counting in C++ (unlikely), that only
> works for my first example, not my second one.

You mean move semantics? You can't move anything if there are existing pointers to it that can't be changed automatically.

On Thursday, 14 July 2016 at 23:38:17 UTC, Walter Bright wrote:
> On 7/14/2016 6:26 AM, Chris wrote:
>> Now, now. Where's your sense of humor?
>
> The thing is, he's just here to troll us. His posts all follow the same pattern of relentlessly finding nothing good whatsoever in D, and we're all idiots.

Whoah, that's sensitive. Never called anyone an idiot, but D zealots seem to have a very low threshold for calling everyone else with a little bit of experience idiots if they see room for change in the language. The excesses of broken argumentation in this newsgroup is keeping change from coming to the language.

It is apparent by now that you and Andrei quite often produce smog screens to cover your trails of broken argument chains, which only serve to defend status quo and not really lead to the language to a competitive position. And no, you are not right just because you declare it, and no if you loose an argument it is not because someone changed the topic.

The sad part about D is that it could've become a major player, but is very unlikely to become one without outside help and less hostile attitude towards rather basic CS. But outside help is not really wanted. Because apparently D can become a major player by 2020 without a cleanup according to you and Andrei.

It is highly unlikely for D to become a major player without language cleanup and opening more up to outside input.