On Tue, 01 May 2012 23:30:27 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> Also, I think you didn't notice the other problem.
>
> The other problem was with IConnection, whose send() wasn't 'const', which also gives you an error due to the transitivity of const (which I've also claimed is broken).
> And how could it? It's just a connection, not a server, so it doesn't parse the input... and it probably changes the state of the connection, since connections often have internal buffers they need to modify (if not prioritization, etc.).
>
> So, what is D's solution for _that_ problem?

There are two solutions, both are horrible.

1. Cast. Coder beware.
2. Store conn outside the instance (i.e. in a hash lookup).  Horrible.

There is a possible 3rd solution.  Don't use immutable/const, instead use
information hiding.

In other words, Your class is already technically "immutable", since name
will never mutate beyond the first setting.  This requires coder
discipline, and has no help from the compiler.

But many languages that *don't* have const/immutable do well with this
pattern (think Java strings).

I have periodically mulled the idea of making a library-based solution for
logical const.  I think it would work, but you would have to be extremely
cautious, and you lose some compiler guarantees for it.

The most difficult part to deal with is how to prevent concurrent access,
when an immutable object is always implicitly sharable.

I have another idea which gets around the problem in a different way.  I
think it's essential to bringing arbitrary ranges in line with current
array features.  When I have some time to flesh it out, I'll propose it.
I think we absolutely can't be finished with ranges until this is
implemented.

-Steve

On 2012-05-02 13:41, Chris Cain wrote:

> If that's what you want, then that's precisely what D does. "According
> to the public interface of Student, none of the methods I will use will
> modify the object." As opposed to C++'s method of "According to the
> public interface of student, these methods have comments that say that
> they say they won't change the object, but I can't tell if it does or not."

For D, it's not limited to the public interface. The rules apply to ALL methods and fields.

-- 
/Jacob Carlborg

On Wednesday, 2 May 2012 at 12:19:35 UTC, Jacob Carlborg wrote:
> For D, it's not limited to the public interface. The rules apply to ALL methods and fields.

Indeed. I may have forgot to add "in any way shape form or fashion" to that particular line, but it's important to node that const means it won't change anything about the object (which includes fields).

Which makes much more sense than "logical const" which has completely arbitrary meaning in almost every case I've seen.

On 5/2/12 3:10 AM, Mehrdad wrote:
> Whoa, what?
>
> So you're saying
> "X results in UB"
> means
> "Compiler guarantees X"
> ?
>
>
> By that philosophy, C and C++ are orders of magnitude better than D,
> given how many so-called "guarantees" they make about your code...

Casting away const should be statically disallowed in @safe code.

Andrei

Mehrdad:

> "Lazy-loading" and caching aren't exactly obscure or rarely-used concepts --  which seems to be the way they are portrayed here. They are *bound* to be used in any nontrivial program.

Right.

- - - - - - - - - -

Andrei Alexandrescu:

> Casting away const should be statically disallowed in @safe code.

I agree.

Bye,
bearophile

On Wed, May 02, 2012 at 09:57:58AM -0400, Andrei Alexandrescu wrote: [...]
> Casting away const should be statically disallowed in @safe code.
[...]

Doesn't it already?


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

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? 

> All of that might hold if the compiler could actually make optimizations based on the knowledge that an integer wouldn't overflow. But what optimizations could it make?

Look for "signed integer overflow" here.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html 

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

Bye,
bearophile

"Steven Schveighoffer"  wrote in message news:op.wdokh6vteav7ka@localhost.localdomain...
> There are two solutions, both are horrible.

That's what scares me lol

> There is a possible 3rd solution.  Don't use immutable/const, instead use information hiding.
> In other words, Your class is already technically "immutable", since name will never mutate beyond the first setting.  This requires coder discipline, and has no help from the compiler.

Yup.

> 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.

> I have periodically mulled the idea of making a library-based solution for logical const.  I think it would work, but you would have to be extremely cautious, and you lose some compiler guarantees for it.
> The most difficult part to deal with is how to prevent concurrent access, when an immutable object is always implicitly sharable.

Yeah, 'shared' also suffers from similar limitations...

> I have another idea which gets around the problem in a different way.  I think it's essential to bringing arbitrary ranges in line with current array features.  When I have some time to flesh it out, I'll propose it. I think we absolutely can't be finished with ranges until this is implemented.

Okay nice. I also think this is 100% relevant to the range issue, so I don't think we will see a true fix until this problem is solved.