On Monday, 9 July 2012 at 08:05:01 UTC, Guillaume Chatelet wrote:
Congrats :)
+1 The D community is awesome, and is getting better everyday.
On Thu, 12 Jul 2012 03:18:51 -0400, Christophe Travert
wrote:
"David Piepgrass" , dans le message (digitalmars.D:172007), a écrit :
@mutating class B : A
{
private int _x2;
public @property override x() { return _x2++; }
}
A fun() pure;
You can't cast the result of fun to immutabl
On Wed, 11 Jul 2012 17:20:08 -0400, deadalnix wrote:
Const is a bridge between mutable and immutable world. The guarantee
proposed with const is that it never mutate an immutable data. This is
slightly different than how const is implemented actually, but still
ensure that no immutable dat
On Thursday, July 12, 2012 07:31:02 Christophe Travert wrote:
> "Jonathan M Davis" , dans le message (digitalmars.D:172005), a écrit :
> > On Wednesday, July 11, 2012 13:46:17 Andrei Alexandrescu wrote:
> >> I don't think they should be pure. Do you have reasons to think
> >> otherwise?
> >
> > As
"Jonathan M Davis" , dans le message (digitalmars.D:172005), a écrit :
> On Wednesday, July 11, 2012 13:46:17 Andrei Alexandrescu wrote:
>> I don't think they should be pure. Do you have reasons to think otherwise?
>
> As I understand it, Walter's current plan is to require that opEquals, opCmp,
"David Piepgrass" , dans le message (digitalmars.D:172007), a écrit :
> @mutating class B : A
> {
> private int _x2;
> public @property override x() { return _x2++; }
> }
A fun() pure;
You can't cast the result of fun to immutable, because it may be a B
instance.
On Wednesday, 11 July 2012 at 18:21:24 UTC, Steven Schveighoffer
wrote:
On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix
wrote:
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's
take something
obviou
On Wednesday, July 11, 2012 13:46:17 Andrei Alexandrescu wrote:
> I don't think they should be pure. Do you have reasons to think otherwise?
As I understand it, Walter's current plan is to require that opEquals, opCmp,
toString, and toHash be @safe const pure nothrow - for both classes and
struc
On 11/07/2012 21:45, Steven Schveighoffer wrote:
On Wed, 11 Jul 2012 15:14:19 -0400, deadalnix wrote:
On 11/07/2012 20:53, Steven Schveighoffer wrote:
On Wed, 11 Jul 2012 14:21:24 -0400, Steven Schveighoffer
wrote:
It also seems to allow abuses. For example:
class A
{
private int _x;
pub
Andrei Alexandrescu , dans le message (digitalmars.D:171945), a écrit :
> On 7/11/12 1:40 PM, Jakob Ovrum wrote:
>> Some classes don't lend themselves to immutability. Let's take something
>> obvious like a class object representing a dataset in a database. How is
>> an immutable instance of such a
On Wed, 11 Jul 2012 15:14:19 -0400, deadalnix wrote:
On 11/07/2012 20:53, Steven Schveighoffer wrote:
On Wed, 11 Jul 2012 14:21:24 -0400, Steven Schveighoffer
wrote:
It also seems to allow abuses. For example:
class A
{
private int _x;
public @property x() const { return _x; }
}
class B
On 11/07/2012 20:53, Steven Schveighoffer wrote:
On Wed, 11 Jul 2012 14:21:24 -0400, Steven Schveighoffer
wrote:
It also seems to allow abuses. For example:
class A
{
private int _x;
public @property x() const { return _x; }
}
class B : A
{
private int _x2;
public @property x() { return _x2
On Wed, 11 Jul 2012 14:21:24 -0400, Steven Schveighoffer
wrote:
It also seems to allow abuses. For example:
class A
{
private int _x;
public @property x() const { return _x; }
}
class B : A
{
private int _x2;
public @property x() { return _x2++; }
}
Another abuse:
cons
On 07/11/2012 08:18 PM, Andrei Alexandrescu wrote:
On 7/11/12 2:07 PM, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 01:49:53PM -0400, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take
something obvious like a class obj
On Wed, 11 Jul 2012 14:29:28 -0400, deadalnix wrote:
On 11/07/2012 20:21, Steven Schveighoffer wrote:
On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix
wrote:
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutab
On Wednesday, 11 July 2012 at 18:21:24 UTC, Steven Schveighoffer
wrote:
...
It also seems to allow abuses. For example:
class A
{
private int _x;
public @property x() const { return _x; }
}
class B : A
{
private int _x2;
public @property x() { return _x2++; }
}
Now I've completel
On 11/07/2012 20:21, Steven Schveighoffer wrote:
On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix wrote:
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take
something
obvious like a class object re
On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix wrote:
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take
something
obvious like a class object representing a dataset in a database. How
is
an
On 07/11/2012 08:17 PM, Andrei Alexandrescu wrote:
On 7/11/12 2:03 PM, Timon Gehr wrote:
I think they should be pure as much as I think they should be const.
The reasoning is analogous for both.
We have immutable class instances that want to provide the methods =>
make them const.
We have pur
On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as a language feature. But
conservative type systems are not good for everything. The
root of the class hierarchy needs to be good for everything.
Object i
On 7/11/12 2:07 PM, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 01:49:53PM -0400, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take
something obvious like a class object representing a dataset in a
database. How is an
On 7/11/12 2:05 PM, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 01:50:23PM -0400, Andrei Alexandrescu wrote:
On 7/11/12 1:49 PM, deadalnix wrote:
I think they should. Comparing the same object 2 time should
definitively have the same result back, otherwise things will go
horribly wrong soon enoug
On Wednesday, 11 July 2012 at 18:10:04 UTC, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 08:01:44PM +0200, deadalnix wrote:
...
Did you saw the proposal of feep/tgehr on #d ?
It basically state that you can overload a const method with a
non
const one if :
- You don't mutate any data that belo
On 7/11/12 2:01 PM, deadalnix wrote:
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take something
obvious like a class object representing a dataset in a database. How is
an immutable instance of
On 7/11/12 2:03 PM, Timon Gehr wrote:
I think they should be pure as much as I think they should be const.
The reasoning is analogous for both.
We have immutable class instances that want to provide the methods =>
make them const.
We have pure functions that want to provide the methods => make
On Wed, Jul 11, 2012 at 08:01:44PM +0200, deadalnix wrote:
> On 11/07/2012 19:49, Andrei Alexandrescu wrote:
> >On 7/11/12 1:40 PM, Jakob Ovrum wrote:
> >>Some classes don't lend themselves to immutability. Let's take something
> >>obvious like a class object representing a dataset in a database. H
On Wed, Jul 11, 2012 at 01:49:53PM -0400, Andrei Alexandrescu wrote:
> On 7/11/12 1:40 PM, Jakob Ovrum wrote:
> >Some classes don't lend themselves to immutability. Let's take
> >something obvious like a class object representing a dataset in a
> >database. How is an immutable instance of such a cl
On 11/07/2012 19:58, Jakob Ovrum wrote:
No, I don't have to do this, your assertion is baseless. The LuaD
library is fairly complete (though there's still a lot of room for
higher-level features), and the example posted works fine and will work
fine for the time being because the aggregate is a s
On 07/11/2012 07:46 PM, Andrei Alexandrescu wrote:
On 7/11/12 1:04 PM, Timon Gehr wrote:
On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for e
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take something
obvious like a class object representing a dataset in a database. How is
an immutable instance of such a class useful?
This is a good
On Wed, Jul 11, 2012 at 01:50:23PM -0400, Andrei Alexandrescu wrote:
> On 7/11/12 1:49 PM, deadalnix wrote:
> >I think they should. Comparing the same object 2 time should
> >definitively have the same result back, otherwise things will go
> >horribly wrong soon enough.
>
> Yah, but e.g. a compari
On Wednesday, 11 July 2012 at 17:47:41 UTC, deadalnix wrote:
To be fair, I know nothing about LUA.
It's "Lua".
But you are talking here about discussing with another
language, so, by definition, don't have the same semantic than
D.
This is irrelevant. The Lua API is a C library like any ot
On 7/11/12 1:49 PM, deadalnix wrote:
I think they should. Comparing the same object 2 time should
definitively have the same result back, otherwise things will go
horribly wrong soon enough.
Yah, but e.g. a comparison may log something.
Andrei
On 11/07/2012 19:32, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 15:59:21 UTC, deadalnix wrote:
If it cannot and should not be const, it isn't a comparison or an
equality test, it is another operation altogether that is performed.
That's bullshit. You've seen the example I raised. How can
On 11/07/2012 19:46, Andrei Alexandrescu wrote:
On 7/11/12 1:04 PM, Timon Gehr wrote:
On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equa
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take something
obvious like a class object representing a dataset in a database. How is
an immutable instance of such a class useful?
This is a good point. It seems we're subjecting all classes to c
On 7/11/12 1:04 PM, Timon Gehr wrote:
On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. B
On Wednesday, 11 July 2012 at 15:27:55 UTC, Andrei Alexandrescu
wrote:
I think I'll find it rather difficult to get behind modeling
arbitrary escapes from immutability. If you want classes, you
buy into a certain contract with inherent rights and
constraints (starting with using references).
On Wednesday, 11 July 2012 at 15:59:21 UTC, deadalnix wrote:
If it cannot and should not be const, it isn't a comparison or
an equality test, it is another operation altogether that is
performed.
That's bullshit. You've seen the example I raised. How can you
tell me it's not an equality test?
On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. But being forced to use const means I ca
On 11/07/2012 18:30, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
[...]
This solution is not for allowing people to use lazy computation in
their const overrides, it's for allowing people to still use
opEquals, toString et
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. But being forced to use const means I can't
cache anything. And this isn't just about cachin
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. But being forced to use const means I can't
cache anything. And this isn't just about cachin
On 7/11/12 12:14 PM, Max Samukha wrote:
Sorry, I misunderstood the question. As I said earlier, the relative
number of lines with 'mutable' is mostly irrelevant. What is more
relevant is the ratio of types defining at least one mutable member to
the total number of types.
I understand that. I w
On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote:
> On 11/07/2012 17:03, Jakob Ovrum wrote:
[...]
> >This solution is not for allowing people to use lazy computation in
> >their const overrides, it's for allowing people to still use
> >opEquals, toString etc. even if their implementations
On 7/11/12 12:12 PM, Timon Gehr wrote:
On 07/11/2012 05:27 PM, Andrei Alexandrescu wrote:
We can't really model every possible design.
If it cannot be modelled, it is not a possible design.
There is if it can be modeled in a less constrained language.
Andrei
On 7/11/12 11:33 AM, Caligo wrote:
About 2 million in C++.
source:
http://www.ohloh.net/p/qt/analyses/latest/languages_summary
I agree that 1500 occurrences of "mutable" in 2 million lines of C++ is
quite large.
Andrei
On 07/11/2012 05:27 PM, Andrei Alexandrescu wrote:
We can't really model every possible design.
If it cannot be modelled, it is not a possible design.
On Wednesday, 11 July 2012 at 15:57:51 UTC, Andrei Alexandrescu
wrote:
On 7/11/12 11:50 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 15:28:41 UTC, Andrei
Alexandrescu wrote:
On 7/11/12 11:11 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei
Alexandrescu wrote:
About 2 million in C++.
source:
http://www.ohloh.net/p/qt/analyses/latest/languages_summary
On Wed, Jul 11, 2012 at 10:28 AM, Andrei Alexandrescu
wrote:
> >
> How many lines total?
>
> Andrei
>
On 11/07/2012 17:49, Timon Gehr wrote:
On 07/11/2012 05:27 PM, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
I was a long-time proponent of this. It's less exciting than it may
seem actually.
(a) Classes that wo
On 7/11/12 11:50 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 15:28:41 UTC, Andrei Alexandrescu wrote:
On 7/11/12 11:11 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei Alexandrescu wrote:
I gave evidence on a large, high quality C++ codebase that the use of
On Wednesday, 11 July 2012 at 15:28:41 UTC, Andrei Alexandrescu
wrote:
On 7/11/12 11:11 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei
Alexandrescu wrote:
I gave evidence on a large, high quality C++ codebase that
the use of
mutable (which is the solution of choic
On 07/11/2012 05:27 PM, deadalnix wrote:
On 11/07/2012 17:03, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
I was a long-time proponent of this. It's less exciting than it may
seem actually.
(a) Classes that work with const just fine incur one extra
On 7/11/12 11:03 AM, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
I was a long-time proponent of this. It's less exciting than it may
seem actually.
(a) Classes that work with const just fine incur one extra virtual
call. I think this can be avoided
On 7/11/12 11:11 AM, Max Samukha wrote:
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei Alexandrescu wrote:
I gave evidence on a large, high quality C++ codebase that the use of
mutable (which is the solution of choice for memoization, caching, and
lazy computation) is extremely scarce.
Wh
On 11/07/2012 17:03, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu wrote:
I was a long-time proponent of this. It's less exciting than it may
seem actually.
(a) Classes that work with const just fine incur one extra virtual
call. I think this can be avoided
On Mon, 09 Jul 2012 07:44:24 -0400, 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 is a reality.
PITA. Forced const can severely harm a code base that wants to be
flexible -- it leaks impl
On Wednesday, 11 July 2012 at 12:39:03 UTC, Andrei Alexandrescu
wrote:
I gave evidence on a large, high quality C++ codebase that the
use of mutable (which is the solution of choice for
memoization, caching, and lazy computation) is extremely scarce.
What evidence do you have for your pred
On 07/11/2012 04:16 PM, deadalnix wrote:
On 11/07/2012 16:16, deadalnix wrote:
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed oft
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu
wrote:
I was a long-time proponent of this. It's less exciting than it
may seem actually.
(a) Classes that work with const just fine incur one extra
virtual call. I think this can be avoided by having the
compiler plant the same
On 07/11/2012 04:16 PM, deadalnix wrote:
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate th
On Wednesday, 11 July 2012 at 13:55:30 UTC, deadalnix wrote:
The cached value can in fact rely outside the object.
For the umpteenth time, I am not talking about caching.
On 07/11/2012 02:40 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:59 AM, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 04:59:28AM +0200, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as
On 07/11/2012 02:39 PM, Andrei Alexandrescu wrote:
On 7/10/12 10:59 PM, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as a language feature. But conservative
type systems are not goo
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
cached value when building the object.
On 11/07/2012 16:16, deadalnix wrote:
On 11/07/2012 16:04, Timon Gehr wrote:
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
c
On 07/11/2012 02:58 PM, deadalnix wrote:
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
cached value when building the object.
And sometimes it is not known in advan
On 11/07/2012 03:30, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 01:19:16 UTC, Andrei Alexandrescu wrote:
On 7/10/12 6:05 PM, Walter Bright wrote:
A straightforward workaround is to use PIMPL to encapsulate the logical
const stuff, and then cast the reference to const to use inside the
opE
I don't think that is a big issue.
Either the value isn't accessed often, and then it make no sense to
cache it, or it is accessed often and it make sense to precalculate the
cached value when building the object.
Doing the calculation at that point avoid synchronization cost involved
otherw
On 7/11/12 12:59 AM, H. S. Teoh wrote:
On Wed, Jul 11, 2012 at 04:59:28AM +0200, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as a language feature. But
conservative type systems ar
On 7/10/12 10:33 PM, Jonathan M Davis wrote:
Yeah. It seems to me that a reasonable approach would be to give Object two
versions of opEquals, opCmp, toString, and toHash - a const and non-const
version of each. The non-const version then calls the const version. So, the
normal thing to do is hav
On 7/10/12 10:22 PM, Walter Bright wrote:
On 7/10/2012 6:53 PM, Andrei Alexandrescu wrote:
On 7/10/12 9:14 PM, Walter Bright wrote:
Anyhow, the point of @trusted is to notify the maintainer that "here be
dragons".
I think that's not representing @trusted quite accurately. There's no
dragon
th
On 2012-07-11 02:03, Walter Bright wrote:
So do I. But all language design involves tradeoffs. I believe the
advantages of const toHash etc. outweigh the disadvantage of less
straightforward memoization.
Can't there be non-const versions of these methods as well?
--
/Jacob Carlborg
On Wed, Jul 11, 2012 at 04:59:28AM +0200, Jakob Ovrum wrote:
> On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu
> wrote:
> >On 7/10/12 9:45 PM, Timon Gehr wrote:
> >>I do not desire logical const as a language feature. But
> >>conservative type systems are not good for everything. Th
On Wednesday, 11 July 2012 at 02:55:33 UTC, Jakob Ovrum wrote:
On Wednesday, 11 July 2012 at 02:33:53 UTC, Jonathan M Davis
wrote:
-snip-
So, with that, we can have const work wonderfully without
requiring it, even
if it does take a bit of work to get around it with classes.
So, what am I
mis
On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as a language feature. But
conservative
type systems are not good for everything. The root of the class
hierarchy needs to be good for everything. Object is
On Wednesday, 11 July 2012 at 02:33:53 UTC, Jonathan M Davis
wrote:
-snip-
So, with that, we can have const work wonderfully without
requiring it, even
if it does take a bit of work to get around it with classes.
So, what am I
missing here? Why doesn't this work? Or has Walter just not
proper
On 7/10/2012 7:42 PM, Timon Gehr wrote:
On 07/11/2012 04:30 AM, Walter Bright wrote:
On 7/10/2012 6:07 PM, Timon Gehr wrote:
(conceptually, the structures are immutable and infinite.)
What a minute - how are you doing toHash for an infinite structure?
The only way you could is by doing toHa
On 07/11/2012 04:02 AM, Andrei Alexandrescu wrote:
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as a language feature. But conservative
type systems are not good for everything. The root of the class
hierarchy needs to be good for everything. Object is not an adequate
root
On 07/11/2012 04:30 AM, Walter Bright wrote:
On 7/10/2012 6:07 PM, Timon Gehr wrote:
(conceptually, the structures are immutable and infinite.)
What a minute - how are you doing toHash for an infinite structure?
The only way you could is by doing toHash on the initial condition for
it. And t
On 7/10/2012 6:07 PM, Timon Gehr wrote:
(conceptually, the structures are immutable and infinite.)
What a minute - how are you doing toHash for an infinite structure?
The only way you could is by doing toHash on the initial condition for it. And
that could be made const.
Same for opEquals.
On Wednesday, July 11, 2012 03:30:43 Jakob Ovrum wrote:
> Honestly, I think the ideal would be to give people the
> alternative of having a mutable opEquals etc. These methods only
> need to be logically constant (of course, they don't *need* to be
> even that, to the joy of operator overloading ab
On 7/10/2012 6:53 PM, Andrei Alexandrescu wrote:
On 7/10/12 9:14 PM, Walter Bright wrote:
Anyhow, the point of @trusted is to notify the maintainer that "here be
dragons".
I think that's not representing @trusted quite accurately. There's no dragon
there. @trusted means "the code is correct bu
On 7/10/12 9:45 PM, Timon Gehr wrote:
I do not desire logical const as a language feature. But conservative
type systems are not good for everything. The root of the class
hierarchy needs to be good for everything. Object is not an adequate
root any more.
How about we consider just stiffening t
On 7/10/12 9:14 PM, Walter Bright wrote:
Anyhow, the point of @trusted is to notify the maintainer that "here be
dragons".
I think that's not representing @trusted quite accurately. There's no
dragon there. @trusted means "the code is correct but not mechanically
checkable". Casting away cons
On 7/10/12 8:03 PM, Walter Bright wrote:
On 7/10/2012 4:29 PM, Timon Gehr wrote:
On 07/11/2012 01:10 AM, Walter Bright wrote:
On 7/10/2012 3:49 PM, Timon Gehr wrote:
I understand, but the downside of not making these functions const
is it
will torpedo the use of functional style programming in
On 7/10/12 7:10 PM, Walter Bright wrote:
PIMPL means pointer to implementation. Your const struct is just a
wrapper around a pointer, and that pointer can be cast to mutable before
calling member functions on it.
Or:
bool opEquals(const Object p) const
{
Object q = cast() p;
Object r = cast() t
On 07/11/2012 03:14 AM, Walter Bright wrote:
On 7/10/2012 6:04 PM, Timon Gehr wrote:
Functional means a guarantee against mutability.
Only guaranteed referential transparency is necessary. Eg, 'fun' in the
following code snippet has this property. Even though it mutates global
state and calls
On Wednesday, 11 July 2012 at 01:19:16 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 6:05 PM, Walter Bright wrote:
A straightforward workaround is to use PIMPL to encapsulate
the logical
const stuff, and then cast the reference to const to use
inside the
opEquals.
s/straightforward/awful/
Andr
On Wednesday, 11 July 2012 at 01:19:16 UTC, Andrei Alexandrescu
wrote:
On 7/10/12 6:05 PM, Walter Bright wrote:
A straightforward workaround is to use PIMPL to encapsulate
the logical
const stuff, and then cast the reference to const to use
inside the
opEquals.
s/straightforward/awful/
Andr
On 7/10/12 6:05 PM, Walter Bright wrote:
A straightforward workaround is to use PIMPL to encapsulate the logical
const stuff, and then cast the reference to const to use inside the
opEquals.
s/straightforward/awful/
Andrei
On 7/10/2012 6:07 PM, Timon Gehr wrote:
(conceptually, the structures are immutable and infinite.)
I understand, and those are useful constructs. Something has to give somewhere,
and I believe that the future lies with provable constructs, not with faith
based programming.
On 7/10/2012 6:04 PM, Timon Gehr wrote:
Functional means a guarantee against mutability.
Only guaranteed referential transparency is necessary. Eg, 'fun' in the
following code snippet has this property. Even though it mutates global
state and calls a function that does not have the property.
i
On 07/11/2012 03:04 AM, Timon Gehr wrote:
On 07/11/2012 02:03 AM, Walter Bright wrote:
...
So do I. But all language design involves tradeoffs. I believe the
advantages of const toHash etc. outweigh the disadvantage of less
straightforward memoization.
I use unbounded data structures. Those h
On 07/11/2012 02:03 AM, Walter Bright wrote:
On 7/10/2012 4:29 PM, Timon Gehr wrote:
On 07/11/2012 01:10 AM, Walter Bright wrote:
On 7/10/2012 3:49 PM, Timon Gehr wrote:
I understand, but the downside of not making these functions const
is it
will torpedo the use of functional style programmin
On 7/10/2012 4:29 PM, Timon Gehr wrote:
On 07/11/2012 01:10 AM, Walter Bright wrote:
On 7/10/2012 3:49 PM, Timon Gehr wrote:
I understand, but the downside of not making these functions const is it
will torpedo the use of functional style programming in D.
Making these functions const will t
On 07/11/2012 01:10 AM, Walter Bright wrote:
On 7/10/2012 3:49 PM, Timon Gehr wrote:
I understand, but the downside of not making these functions const is it
will torpedo the use of functional style programming in D.
Making these functions const will torpedo the use of OO style
programming in
On 7/10/2012 3:49 PM, Timon Gehr wrote:
I understand, but the downside of not making these functions const is it
will torpedo the use of functional style programming in D.
Making these functions const will torpedo the use of OO style programming in D.
No, it won't, there are simple workaroun
On 07/11/2012 12:05 AM, Walter Bright wrote:
On 7/9/2012 3:27 PM, Jakob Ovrum wrote:
This opEquals is only logically constant, not bitwise constant, hence
it must
not be const; similar to the caching scenario. Just trying to
demonstrate that
the issue is bigger than just caching - it's any logic
1 - 100 of 123 matches
Mail list logo
