On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
<brunodomedeiros+s...@com.gmail> wrote:
On 02/12/2010 21:04, Steven Schveighoffer wrote:
On Thu, 02 Dec 2010 13:57:04 -0500, Bruno Medeiros
<brunodomedeiros+s...@com.gmail> wrote:
On 29/11/2010 14:56, Steven Schveighoffer wrote:
This has been discussed at length on this newsgroup, and I argued for
it
for a long time. You will not get any traction with Walter, because
I've already proven that logical const == const, and it still doesn't
change his mind.
Could you detail a bit what do you mean by logical const == const ?
That doesn't sound right to me.
Here is where I show how logical const already exists, it's just clunky
to use.
BTW, this was before TLS, so the example would have to be updated a bit.
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=58927
-Steve
Ok. Well, for starters the "const" functions that mutate the object
state cannot be pure. (if you manage to mutate it without casts in a
pure function, it's because of a compiler bug)
Yes, pure requires special handling. I believe that mutable-marked
members of an object should not be considered part of the object, just
related to the object. So it would make sense to disallow access to those
members in pure functions when the objects are const or immutable. It
would at least make the semantics the same as logical const is defined
here. When the object itself is not const or immutable, I think possibly
access to the mutable members should be allowed, but I haven't worked
through the details in my head yet.
Second, there's the TLS thing. I don't think you can just "update it a
bit", there would be significant changes, maybe not in code size, but in
runtime effect: You would need to make it global shared, and thus have
to synchronize the access to the _mutable global. This is quite
significant.
I actually re-read the code and realized that it should work without any
changes (sans the issue you bring up below with implicit sharing of
immutable).
The above are not trivial differences, so I do not agree that it
constitutes full logical const, only a limited form of it. More
concretely, it doesn't constitute logical const in in the sense where
you can use that as argument to say "logical const already exists, it's
just clunky to use", so let's add it to the language formally. Like if
mutable members where just syntax sugar, or a betterment of safety rules.
I disagree, I think it does prove logical const already exists. How do
you define logical const?
There is one thing however that doesn't feel right in all of this, with
regards to passing immutable objects to other threads. But I think I
need to read TDPL concurrency chapter to clarify some things first of
all.
Implicit sharing of immutable is definitely an issue to consider. If an
object is immutable, then the mutable data is also implicitly sharable
since the mutable data rides around with the object. I don't have a good
answer for this yet, but I don't think it's a deal-killer. We may need to
adjust the rules regarding sharing immutable data (i.e. you can't
implicitly share immutable data, but you can cast it to shared to share
it).
I thought implicit unshared felt completely wrong when it was first
introduced, now I think it's completely correct.
-Steve
