H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote:
> [...]
> Actually, I think C++ const is not very useful, because it guarantees
> nothing. At the most, it's just a sanity checker to make sure the
> programmer didn't accidentally do something dumb. But given an opaque
> C++ function that takes const parameters, there is ZERO guarantee that
> it doesn't actually modify stuff behind your back, and do so legally
> (per spec).

No, casting away const on pointers and references is only legal if the object pointed to is actually mutable (not const). Everything else is UB. Casting away const of a function parameter that is not under your control will sooner or later lead to UB.

Tobi

On Tuesday, August 28, 2018 11:31:40 PM MDT Walter Bright via Digitalmars-d wrote:
> On 8/28/2018 6:39 AM, Iain Buclaw wrote:
> > Template emission strategy is a mess, we're better off just instantiating all templates in all compilation units, and let the compiler decide whatever to discard. Even -allinst does not instantiate enough to allow the compiler to make such decisions that C++ has no problem with (most of the time).
>
> Martin and I proposed a simple strategy for that, but Kenji implemented a different algorithm that nobody understands, and has proved inadequate. There are a couple unresolved bug reports on that.

Would it make sense then to change it to work more like what you and Martin were thinking of doing?

- Jonathan M Davis

On 8/28/2018 11:52 PM, Jonathan M Davis wrote:
> Would it make sense then to change it to work more like what you and Martin
> were thinking of doing?

Yes, it would. But it would be a non-trivial effort to remove Kenji's design.

On 8/26/2018 6:09 PM, Jonathan M Davis wrote:
> I don't know what Walter's current plans are for what any built-in
> ref-counting solution would look like, but it's my understanding that
> whatever he was working on was put on hold, because he needed something like
> DIP 1000 in order to make it work with @safe - which is what then triggered
> his working on DIP 1000 like he has been. So, presumably, at some point
> after DIP 1000 is complete and ready, he'll work on the ref-counting stuff
> again. So, while we may very well get it, I expect that it will be a while.

DIP1000 is needed to make ref counting memory safe.

Andrei is working on ref counting, and he's concluded that copy constructors are a key feature to make them work. Postblits are, sadly, a great idea that are just a failure.

Hence, dip1000 and copy constructors (Razvan is working on that) are key technologies.

On Wednesday, August 29, 2018 2:37:17 AM MDT Walter Bright via Digitalmars-d wrote:
> On 8/28/2018 11:52 PM, Jonathan M Davis wrote:
> > Would it make sense then to change it to work more like what you and Martin were thinking of doing?
>
> Yes, it would. But it would be a non-trivial effort to remove Kenji's design.

Well, then at least it should be an issue of time and manpower rather than it being something that we can't reasonably fix from a technical perspective. So, then presumably, it's a question of priority and whether it's a pressing enough issue to merit the pain of sorting it out - not that the todo list is ever really getting shorter around here...

- Jonathan M Davis

On Wed, Aug 29, 2018 at 01:02:54AM +0000, tide via Digitalmars-d wrote: [...]
> Point being, there is a huge difference between what you were saying, and what you are saying now. "This data never changes" is a much better guarantee and check than "this code does not modify this data". You use const to make sure the data doesn't change, if you can't guarantee it doesn't change from any other code then I wouldn't say it is machine-verifiable.

You appear to be still misunderstanding how it works.  In D, if you want to make sure the data never changes, you use immutable.  Const is for when you want to make sure a piece of code doesn't modify the data (even if the data is mutable elsewhere).  Both are machine-verifiable. As in, the compiler can verify that the code never touches the data.  Immutable provides the strongest guarantee (no code anywhere modifies this data), while const provides a weaker guarantee (this code doesn't modify this data, but somebody else might).

The usefulness of const is that you can safely pass *both* mutable and immutable data through it, and you're guaranteed there will be no problems, because const does not allow the code to touch the data. If the code does not need to touch the data, then it could take the data as const, and you could use the same code to handle both mutable and immutable data.

All of this breaks down if you allow const to be overridden anywhere. That's why it's UB to cast away const.


> So we would need another qualifier "tantamount" to be implemented then it seems.

I don't understand what you mean by this. Could you clarify?


T

-- 
Живёшь только однажды.

On 08/22/2018 10:20 PM, Nicholas Wilson wrote:

> That reminds me, what happened to our conversation with Ali Çehreli about splitting general [newsgroup/forum] into Technical and less technical?

Even I remember that conversation. :) I don't remember who were involved but as soon as I opened the discussion at the next dinner table, I was discouraged; I think people were against the idea.

Ali

On 27.08.2018 11:14, Chris wrote:
> 
> It is unrealistic to assume that code will never break. But as I said in my post above, dmd should give guarantees of backward compatibility of at least N versions. Then we could be more relaxed about our code.

Each breaking change occurs between two adjacent compiler versions.

On 28.08.2018 19:02, H. S. Teoh wrote:
> On Tue, Aug 28, 2018 at 08:18:57AM +0000, Eugene Wissner via Digitalmars-d wrote:
> [...]
>> There are still valid use cases where const should be "broken". One of
>> them is mutex (another one caching). I have very little experiance in
>> multi-threaded programming, but what do you think about "mutable"
>> members, despite the object is const?
> The problem with compromising const is that it would invalidate any
> guarantees const may have provided.

No. You start with the set of allowed program rewrites, then require code with __mutable to not break under them. Code using __mutable is unsafe.

> Const in D is not the same as const
> in languages like C++; const in D means*physical*  const, as in, the
> data might reside in ROM where it's physically impossible to modify.
> Allowing the user to bypass this means UB if the data exists in ROM.
> 
> Plus, the whole point of const in D is that it is machine-verifiable,
> i.e., the compiler checks that the code does not break const in any way
> and therefore you are guaranteed (barring compiler bugs) that the data
> does not change.  If const were not machine-verifiable, it would be
> nothing more than programming by convention, since it would guarantee
> nothing.  Allowing const to be "broken" somewhere would mean it's no
> longer machine-verifiable (you need a human to verify whether the
> semantics are still correct).

It is not unusual to need a human to verify that your code does what it was intended to do.

On 29.08.2018 03:59, Walter Bright wrote:
> There's been some talk of adding a "mutable" qualifier for fields, which would stop the transitivity of const at that point. But it has problems, such as what happens with opaque types. The compiler can no longer check them, and hence will have to assume they contain mutable members.

This is a misunderstanding. The __mutable DIP will define the set of allowed program rewrites based on const/immutable/pure. Then code that uses __mutable must remain correct when they are applied. This achieves two things: it clearly defines the semantics of const/immutable/pure and (the possibility of) __mutable will not be an optimization blocker.

I'll get back to this once I have finished the tuple DIP implementation.