On Wed, May 02, 2012 at 05:16:26PM +0200, bearophile wrote:
> H. S. Teoh:
> 
> >Doesn't it already?
> 
> Right, this:
> 
> class Foo {}
> void main() @safe {
>      const f1 = new Foo;
>      auto f2 = cast(Foo)f1;
> }
> 
> 
> Gives:
> test.d(5): Error: cast from const(Foo) to test.Foo not allowed in
> safe code
[...]

Thought so.

One area where I'd like const to be improved, though, is a way to indicate that const-ness depends on the arguments, specifically, on the behaviour of a delegate argument. For non-delegate arguments we have inout (which is also its own minefield, but anyway), but it sucks that opApply can never be marked @safe, const, or pure because there's no guarantee at all what the delegate will do. (Forcing the delegate to be any of the above is not really an option, because what if you *needed* to call opApply with an impure delegate?)

This on its own is no big deal, but the thing is, const, pure, and @safe are all "viral". All it takes is for a single nested function to call opApply somewhere, and suddenly the whole function call chain can no longer be marked const/pure/@safe.


T

-- 
Let X be the set not defined by this sentence...

"Chris Cain"  wrote in message news:wyqyigxytaqwwmhfhlej@forum.dlang.org...
> If you want just to specify that (and not ask the compiler to check for you), documentation will do.

Heh, if only the world was so ideal...

> That's _any_ kind of modification of state. If you change state, you can't use immutable/const (nor would you really want to).

Okay...


> D's const/immutable require a different way of thinking of it. What are they useful for? Consider a multithreaded program where some threads depend on information that others have.

I guess this answers my question then: const/immutable are useful for multithreading.
So it means, essentially, they're pretty useless for Objects, but only useful for structs.
Why? Objects have **behavior** (not just data), and depending on the _internal details_ of that behavior would be depending on an implementation detail.
Sure, the method writer can call the method 'const', but he really has no idea whether someone will override it down the road and get struck by lightning because of that.

What D's const seems to be is for *data*, pure and simple (no pun intended).
Using it for behavior would be trying to predict the future implementations, and that is pretty damn hard.

Because of that, I think we disallow direct instantiation of const() or immutable() Objects altogether, because they're pretty useless.


> In C++, you'd be foolish to not have locks set up even for const variables because they can change at any time for any reason.

Huh? Not if they're instance variables.
It's kind of silly to lock against something so you can modify instance variables.

> It's hardly a guarantee and it's so common to violate (look at yourself, for instance) that it means _nothing_.]

I don't think I ever violated C++'s 'const'... (?)

> I liked how it was described as a glorified comment, because that's precisely how I think of it.

More like, a **CHECKED** comment.
Big difference. 

Could someone mention a case where it is __necessary__ to cast away const()?
How about immutable()?
How about shared()?

On 2012-05-02 15:13:43 +0000, "Mehrdad" <wfunction@hotmail.com> said:

> Yes, 'const' is part of the interface.
> 
> The trouble is that when you make it part of the interface, you're making the assumption that **no one** who derives from your class will need mutable state.
> 
> How can you ever guarantee that?

When you're making the object 'const', you're not making the assumption that no one who derives from this class need mutable state. What you're doing is asserting that bits belonging to this object needs to be 'const' to preserve sequential consistency across threads or for other reasons. If the derived class casts away const, it breaks that contract.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

> When you're making the object 'const', you're not making the assumption that no one who derives from this class need mutable state.
> What you're doing is asserting that bits belonging to this object needs to be 'const' to preserve sequential consistency across threads or for other reasons.

Bits belonging to *this* object? I thought const was transitive...

> If the derived class casts away const, it breaks that contract.

So you're saying the same thing: Derived classes CANNOT have mutable state... 

On Wednesday, 2 May 2012 at 15:21:31 UTC, Mehrdad wrote:
> "Steven Schveighoffer"  wrote in message news:op.wdokh6vteav7ka@localhost.localdomain...

>> But many languages that *don't* have const/immutable do well with this pattern (think Java strings).
>
> Java strings are pretty poor for performance though. :\
> You shouldn't be forced to choose between O(1) performance (versus O(n)) and the correctness of your program.

This is a false choice.  The performance of Java strings (BTW, which I don't think is that bad) is not tied to whether they are immutable or not.

-Steve

On 02-05-2012 17:58, Mehrdad wrote:
> Could someone mention a case where it is __necessary__ to cast away
> const()?
> How about immutable()?
> How about shared()?

shared? Almost always in any non-trivial application. shared is only useful if you're dealing with templatized functions that can actually handle it, which is not the case as often as one would like.

>


-- 
- Alex

On Wednesday, 2 May 2012 at 16:52:33 UTC, Alex Rønne Petersen wrote:
> shared? Almost always in any non-trivial application. shared is only useful if you're dealing with templatized functions that can actually handle it, which is not the case as often as one would like.

Additionally, shared is currently little more than a marker for non-TLS data.

David

H. S. Teoh:

> One area where I'd like const to be improved, though, is a way to indicate that const-ness depends on the arguments, specifically, on the behaviour of a delegate argument.

There was a long discussion about this, with proposals like @pure(compile_time_predicate) to define a conditional purity. But Walter decided for a simpler solutions, where the purity and "non-throwness" of templates is inferred.

Bye,
bearophile

> This is a false choice.  The performance of Java strings (BTW, which I don't think is that bad) is not tied to whether they are immutable or not.

Oh yes, I think you're right. If I remember, someone told me Java strings don't re-copy data when you substring; I forgot about that.

But that's definitely not the case in C#.