September 12, 2007
Reiner Pope wrote:
> As far as I can see, this re-enables the benefits of transitive const for functional and multi-threaded programming, as the compiler is free to ignore any changes to the variable, just as it is for transitive const.

It doesn't re-enable any benefits, as all the usual synchronization, race conditions, etc., are there in full force. You're back to relying on programmer discipline to make it work right, and experience shows that that doesn't work for multithreading.
September 12, 2007
Janice Caron wrote:
> It's a solution which doesn't scale.
> 
> And there goes encapsulation...

At least for this example, the same issue exists when attempting to do "const-correctness" in C++. You cannot paste const on at the top level, it has to be put in at every level underneath it.
September 12, 2007
Janice Caron wrote:
> Even something as simple as this needs logical const
> 
> class MyMathClass
> {
>     invariant int multiply(int x, int y) /* logically const */
>     {
>         debug logfile.writeLine("multiply.called");
>         return x * y;
>     }
> 
>     debug private Stream logfile;
> }
> 
> You can't tell me that's not a real world need.

You can:

1. make logfile a static member.

2. not use invariant on the multiply. After all, if it isn't actually invariant, the invariant declaration wouldn't have any more meaning than the comment you put on it.
September 12, 2007
Janice Caron Wrote:

> > You obviously missed the discussion of the "pure" keyword, borrowed from Fortran-90 from the conference. This is a clear way of declaring that a function must not have any side-effects.
> 
> 
> Cool!
> 
> But then, I don't understand Walter's objections to "logical constness".
> 
> Seems pretty simple to me. If a function is logically const but not truly const, then don't declare it pure.
> 
> Conversely, if it's not declared pure, then it can have logical constness.
> 
> Isn't that problem solved?

Getting constness and purity mixed up is liable to open a whole new can of worms. I humbly suggest you don't go there.

I not sure whetherpure functions can modify class variables. The presentation states that they can't modify anything reachable through their arguments. If we interpret "this" as a argument then pure methods must also be const in the C++ sense.
September 12, 2007
Carsten Sørensen Wrote:

> Alex Burton wrote:
> > While const is being reexamined....
> > 
> > I create an interface :
> > 
> > interface Server
> > {
> >     Data getData() const;
> > };
> 
> Hello, world! I'm fairly new to the world of D, but a minor detail like that has never stopped me from butting in so far ;) I'm sorry if any of my points have been made before, but I don't really feel like trawling through all 50.000 posts (although I have made an effort to dig into the more recent ones)
> 
> First of all, I think specifying an interface method to be const is bad practice. The interface is assuming things about a possible implementation that is really not its business. As you describe, this will hinder your implementation.
> 
> I understand you're not able to specify your particular getData() implementation as const due to const's transitivity, but as far as I'm concerned them's the breaks. I'm a bit of a const purist, sorry.
> 
> What I would like to see regarding const and interfaces, is that the _implementation_ should be able to guarantee const-correctness even if the interface doesn't, much like covariant return types. The implementation should be free to guarantee more than its interface. That doesn't help you though...
> 
> 
> Best regards,
> Carsten Sørensen

Someone correct me if I'm wrong but I thought D doesn't / wasn't going to support overloading methods on whether they are const or not. So this part of the discussion is almost moot.

Bruce.

September 12, 2007
Bruce Adams wrote:
> Someone correct me if I'm wrong but I thought D doesn't / wasn't going to support overloading methods on whether they are const or not. So this part of the discussion is almost moot.

Sorry if I wasn't totally clear. I'm not talking about overloading, but overriding/implementing and introducing const.


Best regards,
Carsten Sørensen
September 12, 2007
Janice Caron Wrote:

> > I suspect he meant "copy on write", but forget to tell us. :-)
> 
> Here's an example of copy-on-write:
> 
> MyString s = "cat";
> MyString t = s; /* Only a reference is copied. Now s and t both
> reference the same data */
> writefln(t); /* prints "cat" */
> 
> /*drum roll*/
> t[0] = 'b'; /* Only now is a copy made. Now t is unique, with s=="cat"
> and t="bat" */
> writefln(s); /* prints "cat" */
> writefln(t); /* prints "bat" */
> 
> Of course, to implement this - to actually create a class that did this, you'd need MyString to have some internal state (and therefore, either non-transitive const, or logical const).

If you are living in the wonderful world of unix. Copy on write automagically happens for you if you change a value, following a process fork, courtesy of the OS. That's not to say it not a useful technique outside of forking unix processes but the point is that it can happen without any kind of const thrown into the mix.
  I suspect the restrict keyword interacts with this in interesting ways.
Fortunately I've never had to try it myself.

Bruce.
September 12, 2007
"Walter Bright" wrote
> Steven Schveighoffer wrote:

> Although const is necessary for f.p., it is not sufficient for f.p., as your example illustrates.

>
> The thought is to declare a function as 'pure'.

OK, but why not allow BOTH logical const and transitive const?  What if const exists as it does, except the mutable keyword overrides it?  As long as pure functions can only call other pure functions and use const basic types, then isn't f.p. still possible?  You could even use const types that have mutable parts as long as you are only calling pure functions on those types (as those wouldn't be able to access the mutable piece).

>
>
>>> 3) Be able to treat invariant references as value types. This, for example, makes manipulating strings as easy as manipulating ints.
>>
>> I don't understand this, perhaps someone can explain it further.  An example of how this helps would be good.
>
> Strings in, say, Perl or Basic "just work". Just like integers "just work" in C. Nobody ever gives a thought to them inadvertently changing value.
>
> But strings in C, everybody worries about them changing value, and such is a major source of bugs.

I understand why it is good to have strings immutable, as I've used Java
quite a bit.
But how does transitive const guarantee that a string's value won't change?
Don't you just need immutable strings?

What I was looking for is:

example = ???
without transitive const:
life sucks in this example because you can't do ...
with transitive const:
life is better because now I can do ...

>
>>> 4) Makes COW programming checkable and enforceable. (COW programming is an important part of many styles of programming.) Without transitive const, COW is overly reliant on programmer discipline.
>>
>> All I can find on the net about COW programming is the COW programming language.  I'm sure this isn't what you meant :)  can you please explain this further?
>
> copy-on-write

ok, so you are saying that with transitive const, this is enforceable, by the compiler I'm assuming.  Give me an example of how having transitive const makes COW enforceable by the compiler and doesn't rely on the programmer.  I understand much better with examples rather than abstract arguments if you notice :)

-Steve


September 12, 2007
I was trying to simplifly. Sigh. The gist of this particular example is that have what /starts off/ as perfectly good, non-member-modifying code, and all is well. But then you later put in some diagnostics to make it write stuff to a file (coz you're debugging) and suddenly it no longer compiles and you have keep taking const out of your code all over the place until it does.

What about all those other cases? There's a long list of applications there.
September 12, 2007
Carsten Sørensen Wrote:

> Bruce Adams wrote:
> > Someone correct me if I'm wrong but I thought D doesn't / wasn't going to support overloading methods on whether they are const or not. So this part of the discussion is almost moot.
> 
> Sorry if I wasn't totally clear. I'm not talking about overloading, but overriding/implementing and introducing const.
> 
> 
> Best regards,
> Carsten Sørensen

You were totally clear but using a C++ concept of const methods which I believe (and may be wrong) has no analogue in D. I believe the intention was to keep it out of the language as it is an ambomination. That said, I'm not clear how you can get the proper semantics for e.g. overloads of [] in D without it.

Bruce.