On Wednesday, 11 July 2012 at 00:20:32 UTC, Timon Gehr wrote:
I for one would be satisfied if inheriting from object became
optional:
// object.di
class RawObject /+ this is the root of the class hierarchy +/{ }
class SynchronizableObject : RawObject { void* monitor; }
class Object :
David Piepgrass , dans le message (digitalmars.D:172009), a écrit :
Now, I recognize and respect the benefits of transitive
immutability:
1. safe multithreading
2. allowing compiler optimizations that are not possible in C++
3. ability to store compile-time immutable literals in ROM
(3)
On 10/07/12 19:13, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 06:48:51PM +0200, Timon Gehr wrote:
On 07/10/2012 06:45 PM, H. S. Teoh wrote:
Yeah, this is logical const. Unfortunately, D doesn't have logical
const.
Then why on earth is druntime acting as if it does?
Y'know, this brings up
On 2012-07-11 02:20, Timon Gehr wrote:
I for one would be satisfied if inheriting from object became optional:
// object.di
class RawObject /+ this is the root of the class hierarchy +/{ }
class SynchronizableObject : RawObject { void* monitor; }
class Object : SynchronizableObject {
const {
Andrei Alexandrescu , dans le message (digitalmars.D:171828), a écrit :
On 7/10/12 5:19 PM, H. S. Teoh wrote:
There is value in immutable objects that has been well discussed, which
is incompatible with logical constness. We can change the language such
as: a given type X has the option to
On 7/11/12 3:58 AM, Don Clugston wrote:
Something I wonder about, though, is how many different use cases are we
dealing with?
Suppose we had a caching solution (you could think of it as @cached, but
it could be done in a library). The user would need to provide a const,
pure function which
On 7/11/12 8:55 AM, Andrei Alexandrescu wrote:
The cost of getting to the stash is
proportional to the number of objects within the thread that make use of
that stash.
Oops, that would be with linear search :o).
Andrei
On Wednesday, 11 July 2012 at 12:55:39 UTC, Andrei Alexandrescu
wrote:
Any takers for Cached? It would be good to assess its level of
usefulness first.
As for me, lazy computation (with caching) would likely be the
last feature I really miss in D.
On 10/07/2012 22:11, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 12:00:59 H. S. Teoh wrote:
I think hidden somewhere in this is an unconscious conflation of
physical const with logical const.
I completely disagree at least as far as classes go. opEquals, opCmp,
toString, and toHash must
On 11/07/2012 02:20, Timon Gehr wrote:
On 07/11/2012 01:57 AM, Walter Bright wrote:
On 7/10/2012 4:16 PM, Timon Gehr wrote:
Const is stronger than what is required to bridge the gap between
mutable and immutable. It guarantees that a reference cannot be used to
mutate the receiver regardless
On Jul 11, 2012, at 12:58 AM, Don Clugston d...@nospam.com wrote:
On 10/07/12 19:13, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 06:48:51PM +0200, Timon Gehr wrote:
On 07/10/2012 06:45 PM, H. S. Teoh wrote:
Yeah, this is logical const. Unfortunately, D doesn't have logical
const.
Then why
On 07/11/2012 02:55 PM, Andrei Alexandrescu wrote:
...
If this is a useful artifact, Walter had an idea a while ago that we can
have the compiler help by using the per-object monitor pointer instead
of the static hashtable. Right now the pointer points to a monitor
object, but it could point to
On 7/11/12 10:33 AM, Timon Gehr wrote:
Any takers for Cached? It would be good to assess its level of
usefulness first.
Andrei
Well, it is inefficient.
The idea here is to assess functionality provided in order to decide
whether to go down this route or not.
Andrei
On Wednesday, 11 July 2012 at 14:42:43 UTC, Andrei Alexandrescu
wrote:
On 7/11/12 10:33 AM, Timon Gehr wrote:
Any takers for Cached? It would be good to assess its level of
usefulness first.
Andrei
Well, it is inefficient.
The idea here is to assess functionality provided in order to
On Wednesday, 11 July 2012 at 14:42:43 UTC, Andrei Alexandrescu
wrote:
On 7/11/12 10:33 AM, Timon Gehr wrote:
Any takers for Cached? It would be good to assess its level of
usefulness first.
Andrei
Well, it is inefficient.
The idea here is to assess functionality provided in order to
Suppose we had a caching solution (you could think of it as
@cached, but
it could be done in a library). The user would need to provide
a const,
pure function which returns the same value that is stored in
the cache.
This is enforceable. The only way to write to the cache, is by
calling
the
Except that I don't see why Cached!(...) needs to physically
separate the mutable state from the rest of the object. I mean,
I see that Cached!(...) would have to cast away immutable
(break the type system) in order to put mutable state in an
immutable object, but if we set aside the current
On Tuesday, 10 July 2012 at 02:43:05 UTC, Era Scarecrow wrote:
On Tuesday, 10 July 2012 at 01:41:29 UTC, bearophile wrote:
David Piepgrass:
This use case is pretty complex, so if I port this to D, I'd
probably just cast away const/immutable where necessary.
You are not the first person that
On Tue, Jul 10, 2012 at 05:39:45PM +0200, David Piepgrass wrote:
[...]
The difficulty, in case you missed it, is that somebody else (the
Object class) says that certain functions are const, but in certain
cases we really, really want to mutate something, either for
efficiency or because that's
On 07/10/2012 06:45 PM, H. S. Teoh wrote:
Yeah, this is logical const. Unfortunately, D doesn't have logical
const.
Then why on earth is druntime acting as if it does?
On Tue, Jul 10, 2012 at 06:48:51PM +0200, Timon Gehr wrote:
On 07/10/2012 06:45 PM, H. S. Teoh wrote:
Yeah, this is logical const. Unfortunately, D doesn't have logical
const.
Then why on earth is druntime acting as if it does?
Y'know, this brings up an interesting question. Do methods
On Tuesday, July 10, 2012 10:13:57 H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 06:48:51PM +0200, Timon Gehr wrote:
On 07/10/2012 06:45 PM, H. S. Teoh wrote:
Yeah, this is logical const. Unfortunately, D doesn't have logical
const.
Then why on earth is druntime acting as if it does?
On Tue, Jul 10, 2012 at 02:04:04PM -0400, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 10:13:57 H. S. Teoh wrote:
[...]
Y'know, this brings up an interesting question. Do methods like
toString _need_ to be const? That is, _physical_ const? Or are we
unconsciously conflating physical
On Tuesday, July 10, 2012 12:00:59 H. S. Teoh wrote:
I think hidden somewhere in this is an unconscious conflation of
physical const with logical const.
I completely disagree at least as far as classes go. opEquals, opCmp,
toString, and toHash must be _physically_ const, because they must work
On Tue, Jul 10, 2012 at 04:11:05PM -0400, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 12:00:59 H. S. Teoh wrote:
I think hidden somewhere in this is an unconscious conflation of
physical const with logical const.
I completely disagree at least as far as classes go. opEquals, opCmp,
On Tuesday, July 10, 2012 14:19:46 H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 04:11:05PM -0400, Jonathan M Davis wrote:
On Tuesday, July 10, 2012 12:00:59 H. S. Teoh wrote:
I think hidden somewhere in this is an unconscious conflation of
physical const with logical const.
I completely
On Tuesday, 10 July 2012 at 21:18:18 UTC, H. S. Teoh wrote:
If I'm OK with physical const, then all is fine and
dandy. But as soon as one thing can't be const, I've to
re-engineer my
entire framework from ground up.
Isn't there something we can do to improve this situation?
T
I don't
On Tue, Jul 10, 2012 at 11:59:48PM +0200, Jakob Ovrum wrote:
On Tuesday, 10 July 2012 at 21:18:18 UTC, H. S. Teoh wrote:
If I'm OK with physical const, then all is fine and dandy. But as
soon as one thing can't be const, I've to re-engineer my entire
framework from ground up.
Isn't there
On 7/10/2012 3:13 PM, H. S. Teoh wrote:
I don't think they were rushed. There's been a push for making druntime
and Phobos const-correct for a while now. I don't think this change is a
_mistake_ per se, but it does expose a flaw in the language: const is
too limited in scope, and we need
On Tue, Jul 10, 2012 at 03:39:30PM -0700, Walter Bright wrote:
On 7/10/2012 3:13 PM, H. S. Teoh wrote:
I don't think they were rushed. There's been a push for making
druntime and Phobos const-correct for a while now. I don't think this
change is a _mistake_ per se, but it does expose a flaw in
On Tuesday, 10 July 2012 at 22:12:35 UTC, H. S. Teoh wrote:
I don't think we want to change physical (bitwise) const. It
does have
its uses, and it's necessary if you want immutable to work
nicely with
mutable. But if the current const is all we have, then IMO
something is
missing from the
On 7/10/2012 4:05 PM, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 03:39:30PM -0700, Walter Bright wrote:
On 7/10/2012 3:13 PM, H. S. Teoh wrote:
I don't think they were rushed. There's been a push for making
druntime and Phobos const-correct for a while now. I don't think this
change is a
On Tue, Jul 10, 2012 at 04:05:51PM -0700, Walter Bright wrote:
On 7/10/2012 4:05 PM, H. S. Teoh wrote:
[...]
What about the partial const idea I had?
Given a class C which derives from a base class B, we may designate
the base class B as const, which makes every inherited field const,
while
On 07/11/2012 12:39 AM, Walter Bright wrote:
On 7/10/2012 3:13 PM, H. S. Teoh wrote:
I don't think they were rushed. There's been a push for making druntime
and Phobos const-correct for a while now. I don't think this change is a
_mistake_ per se, but it does expose a flaw in the language:
On 7/10/2012 4:16 PM, Timon Gehr wrote:
Const is stronger than what is required to bridge the gap between
mutable and immutable. It guarantees that a reference cannot be used to
mutate the receiver regardless of whether or not the receiver is
immutable underneath. That is unnecessary as far as
On 7/10/2012 4:19 PM, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 04:05:51PM -0700, Walter Bright wrote:
On 7/10/2012 4:05 PM, H. S. Teoh wrote:
[...]
What about the partial const idea I had?
Given a class C which derives from a base class B, we may designate
the base class B as const, which
On 07/11/2012 01:57 AM, Walter Bright wrote:
On 7/10/2012 4:16 PM, Timon Gehr wrote:
Const is stronger than what is required to bridge the gap between
mutable and immutable. It guarantees that a reference cannot be used to
mutate the receiver regardless of whether or not the receiver is
On Tue, Jul 10, 2012 at 04:58:06PM -0700, Walter Bright wrote:
On 7/10/2012 4:19 PM, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 04:05:51PM -0700, Walter Bright wrote:
On 7/10/2012 4:05 PM, H. S. Teoh wrote:
[...]
Nqt in this case. The const(B) reference does not permit any of B's
methods to
On 7/10/12 5:19 PM, H. S. Teoh wrote:
Isn't there something we can do to improve this situation?
There is, only thing is there's no easy way (without adding some amount
of complication to the language).
Generally const(T) is a supertype of T and immutable(T), meaning it
could originate
On 7/10/12 6:39 PM, Walter Bright wrote:
On 7/10/2012 3:13 PM, H. S. Teoh wrote:
I don't think they were rushed. There's been a push for making druntime
and Phobos const-correct for a while now. I don't think this change is a
_mistake_ per se, but it does expose a flaw in the language: const is
On 7/10/12 7:58 PM, Walter Bright wrote:
If you've found a way to mutate const and have it stay const, then
there's a hole in the typing system.
No. This is dogma devoid of substance. Maybe you found a way to
initialize on first read, and suddenly there's a viable type system.
Andrei
On 07/11/2012 03:43 AM, Andrei Alexandrescu wrote:
On 7/10/12 6:39 PM, Walter Bright wrote:
On 7/10/2012 3:13 PM, H. S. Teoh wrote:
I don't think they were rushed. There's been a push for making druntime
and Phobos const-correct for a while now. I don't think this change is a
_mistake_ per se,
On 7/10/12 7:57 PM, Walter Bright wrote:
On 7/10/2012 4:16 PM, Timon Gehr wrote:
Const is stronger than what is required to bridge the gap between
mutable and immutable. It guarantees that a reference cannot be used to
mutate the receiver regardless of whether or not the receiver is
immutable
On Monday, 9 July 2012 at 16:02:38 UTC, Timon Gehr wrote:
On 07/09/2012 05:00 PM, H. S. Teoh wrote:
On Mon, Jul 09, 2012 at 01:44:24PM +0200, Timon Gehr wrote:
On 07/09/2012 08:37 AM, Adam Wilson wrote:
Object is now const-correct throughout D. This has been a
dream for many of you. Today it
On Monday, July 09, 2012 18:34:14 David Piepgrass wrote:
I guess D does not have 'mutable' (like C++) to override const on
methods?
No, const is actually const. You can't modify anything which is const through
that reference (or pointer) to that data. Casting away const and mutating
something
On 7/9/12 12:34 PM, David Piepgrass wrote:
I guess D does not have 'mutable' (like C++) to override const on
methods?
It doesn't, which makes life difficult for certain idioms. On the
upside, you can assume more than C++ does about immutable data.
Caching anything slow-to-compute is my
On 07/09/2012 07:49 PM, Andrei Alexandrescu wrote:
On 7/9/12 12:34 PM, David Piepgrass wrote:
I guess D does not have 'mutable' (like C++) to override const on
methods?
It doesn't, which makes life difficult for certain idioms. On the
upside, you can assume more than C++ does about immutable
On Mon, Jul 09, 2012 at 08:07:22PM +0200, Timon Gehr wrote:
On 07/09/2012 07:49 PM, Andrei Alexandrescu wrote:
On 7/9/12 12:34 PM, David Piepgrass wrote:
I guess D does not have 'mutable' (like C++) to override const on
methods?
It doesn't, which makes life difficult for certain idioms. On
On Monday, July 09, 2012 11:53:05 H. S. Teoh wrote:
I'm wondering if it makes any sense to have _also_ have non-const
versions of things like toString, for objects that want to implement
caching. So in contexts where const is not important, you can have
caching, network access, whatever you
David Piepgrass:
This use case is pretty complex, so if I port this to D, I'd
probably just cast away const/immutable where necessary.
You are not the first person that says similar things. So D docs
need to stress more than casting away const/immutable in D is
rather more dangerous than
On Tuesday, 10 July 2012 at 01:41:29 UTC, bearophile wrote:
David Piepgrass:
This use case is pretty complex, so if I port this to D, I'd
probably just cast away const/immutable where necessary.
You are not the first person that says similar things. So D
docs need to stress more than
51 matches
Mail list logo
