View mode: basic / threaded / horizontal-split · Log in · Help
September 12, 2007
Re: Transitive const sucks
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
Re: Transitive const sucks
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
Re: Transitive const sucks
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
Re: Transitive const sucks (pure)
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
Re: Transitive const sucks
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
Re: Transitive const sucks
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
Re: Transitive const sucks
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
Re: Transitive const sucks
"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
Re: Transitive const sucks
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
Re: Transitive const sucks
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.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home