IMHO only practically usable "logical const" alternative in D are
getters (in absence of setters). For all other cases better to
simply abandon the concept, it simply does not fit the type
system.
On Sunday, February 16, 2014 06:55:36 Stanislav Blinov wrote:
> On Sunday, 16 February 2014 at 06:28:45 UTC, Jonathan M Davis
>
> wrote:
> > On Sunday, February 16, 2014 03:25:08 Stanislav Blinov wrote:
> >> On Saturday, 15 February 2014 at 04:03:51 UTC, Adam D. Ruppe
> >> wrote:
> >>
> >> What a
On Sunday, 16 February 2014 at 06:28:45 UTC, Jonathan M Davis
wrote:
On Sunday, February 16, 2014 03:25:08 Stanislav Blinov wrote:
On Saturday, 15 February 2014 at 04:03:51 UTC, Adam D. Ruppe
wrote:
What about a library solution for something like C++-esque
mutable?
You're casting away const
re arguing about. I'm saying that if
> you pass mutable data to an inout function, inout effectively
> acts as logical const within that function, as the compiler
> doesn't allow you to modify the inout function argument but it is
> safe to cast away inout. Do you agree or dis
On Sunday, February 16, 2014 03:25:08 Stanislav Blinov wrote:
> On Saturday, 15 February 2014 at 04:03:51 UTC, Adam D. Ruppe
> wrote:
>
> What about a library solution for something like C++-esque
> mutable?
You're casting away const if you do that, and that's precisely what you
shouldn't be doi
On Sun, 16 Feb 2014 00:22:33 -0500, Steven Schveighoffer
wrote:
The problem you have to solve is this:
void foo(const(int) t)
Gahh... should have been:
void foo(ref const(int) t)
-Steve
On Sun, 16 Feb 2014 00:14:07 -0500, Meta wrote:
On Sunday, 16 February 2014 at 04:46:34 UTC, Steven Schveighoffer wrote:
It is safe if you can guarantee the input is ultimately mutable. But
there is no way to enforce such a guarantee. It is on the caller to
make sure that is true.
I don't
On Sunday, 16 February 2014 at 04:46:34 UTC, Steven Schveighoffer
wrote:
It is safe if you can guarantee the input is ultimately
mutable. But there is no way to enforce such a guarantee. It is
on the caller to make sure that is true.
I don't see why inout should be identified as any different
f you pass
mutable data to an inout function, inout effectively acts as logical
const within that function, as the compiler doesn't allow you to modify
the inout function argument but it is safe to cast away inout. Do you
agree or disagree with this?
It is safe if you can guarante
effectively
acts as logical const within that function, as the compiler
doesn't allow you to modify the inout function argument but it is
safe to cast away inout. Do you agree or disagree with this?
On Sat, 15 Feb 2014 22:17:48 -0500, Meta wrote:
On Sunday, 16 February 2014 at 03:16:16 UTC, Steven Schveighoffer wrote:
On Sat, 15 Feb 2014 22:04:25 -0500, Meta wrote:
Obviously this is extremely contrived, but inout is effectively
logical const here. Is there no way to know what the
On Saturday, 15 February 2014 at 04:03:51 UTC, Adam D. Ruppe
wrote:
What about a library solution for something like C++-esque
mutable?
struct Mutable(T)
{
private T val;
this(T v) { val = v; }
@property ref T get() const { return *cast(T*)&val; }
alias get this;
}
import s
On Sunday, 16 February 2014 at 03:16:16 UTC, Steven Schveighoffer
wrote:
On Sat, 15 Feb 2014 22:04:25 -0500, Meta
wrote:
Obviously this is extremely contrived, but inout is
effectively logical const here. Is there no way to know what
the "original" mutability of t is at compile-
On Sat, 15 Feb 2014 22:04:25 -0500, Meta wrote:
Obviously this is extremely contrived, but inout is effectively logical
const here. Is there no way to know what the "original" mutability of t
is at compile-time?
No, because only one version of the function is generated. That
logicalConstBump(T)(ref inout(T) t, string
originalMutability)
{
if (originalMutability == "mutable")
{
cast(T)t += 1;
}
else
{
assert(0);
}
}
Obviously this is extremely contrived, but inout is effectively
logical const here. Is there no way to know what the
On Sat, 15 Feb 2014 21:36:43 -0500, Meta wrote:
On Sunday, 16 February 2014 at 02:34:36 UTC, Steven Schveighoffer wrote:
On Sat, 15 Feb 2014 15:02:44 -0500, Meta wrote:
On Saturday, 15 February 2014 at 19:59:07 UTC, Meta wrote:
inout is *sort of* logical const, if the underlying type is
On Sunday, 16 February 2014 at 02:34:36 UTC, Steven Schveighoffer
wrote:
On Sat, 15 Feb 2014 15:02:44 -0500, Meta
wrote:
On Saturday, 15 February 2014 at 19:59:07 UTC, Meta wrote:
inout is *sort of* logical const, if the underlying type is
immutable.
I mean mutable, of course.
No, it
On Fri, 14 Feb 2014 23:03:50 -0500, Adam D. Ruppe
wrote:
D doesn't have logical const, but sometimes it is useful, especially
with lazy initialization of a field, and we can kinda fake it with casts
or with global variables. Modifying an immutable object is undefined
behavior, s
On Sat, 15 Feb 2014 15:02:44 -0500, Meta wrote:
On Saturday, 15 February 2014 at 19:59:07 UTC, Meta wrote:
inout is *sort of* logical const, if the underlying type is immutable.
I mean mutable, of course.
No, it's not. It's not allowed to mutate with inout.
-Steve
On Saturday, 15 February 2014 at 19:59:07 UTC, Meta wrote:
inout is *sort of* logical const, if the underlying type is
immutable.
I mean mutable, of course.
On Saturday, 15 February 2014 at 12:23:54 UTC, Peter Alexander
wrote:
If you want logical const in D, you just don't use const. If
you try to hack around it, it will just come back and bite you.
As a result, when writing APIs, don't enforce constness of your
parameters if you requi
On 02/15/2014 08:34 PM, Jesse Phillips wrote:
But mutating a mutable address is still valid, so as long as _you_
guarantee the address is not immutable, no it won't format your harddrive.
class C{ bool doit = true; }
void foo(const(C) c)pure{ (cast()C).doit = false; }
void main(){
auto c =
On Saturday, 15 February 2014 at 12:23:54 UTC, Peter Alexander
wrote:
If you want logical const in D, you just don't use const. If
you try to hack around it, it will just come back and bite you.
As a result, when writing APIs, don't enforce constness of your
parameters if you requi
If you want logical const in D, you just don't use const. If you
try to hack around it, it will just come back and bite you.
As a result, when writing APIs, don't enforce constness of your
parameters if you require logical const. e.g. a range will not
necessarily have const front
On Saturday, 15 February 2014 at 10:52:25 UTC, Jonathan M Davis
wrote:
If you want logical const, don't use const or immutable at all.
To do so is
undefined as they require physical constness/immutability. So,
if you want
logical const, you need to indicate constness in some other way
t
On Saturday, February 15, 2014 04:03:50 Adam D. Ruppe wrote:
> D doesn't have logical const, but sometimes it is useful,
> especially with lazy initialization of a field, and we can kinda
> fake it with casts or with global variables. Modifying an
> immutable object is undefined
D doesn't have logical const, but sometimes it is useful,
especially with lazy initialization of a field, and we can kinda
fake it with casts or with global variables. Modifying an
immutable object is undefined behavior, so how can we avoid that,
and if not, try to minimize the proble
On Monday, 14 May 2012 at 21:19:43 UTC, Steven Schveighoffer
wrote:
On Mon, 14 May 2012 17:11:14 -0400, Alex Rønne Petersen
wrote:
Another concern I have is that this couples a feature tightly
to the implementation of the GC. What if another GC doesn't
use the same allocation scheme?
newScr
On Mon, 14 May 2012 17:11:14 -0400, Alex Rønne Petersen
wrote:
Another concern I have is that this couples a feature tightly to the
implementation of the GC. What if another GC doesn't use the same
allocation scheme?
newScratchSpace uses GC.malloc to ensure the block is big enough. The GC
On 14-05-2012 21:51, Steven Schveighoffer wrote:
I have an idea on how to create logical const without any language or
compiler changes -- it will exist purely in druntime.
The idea is based on this: Whenever you allocate an object, you use a
memory block. An object, by default, has the
On 14-05-2012 23:06, Alex Rønne Petersen wrote:
On 14-05-2012 22:13, Steven Schveighoffer wrote:
On Mon, 14 May 2012 15:56:37 -0400, Alex Rønne Petersen
wrote:
On 14-05-2012 21:51, Steven Schveighoffer wrote:
It also should be recommended that the scratch space not contain any GC
pointers,
On 14-05-2012 22:13, Steven Schveighoffer wrote:
On Mon, 14 May 2012 15:56:37 -0400, Alex Rønne Petersen
wrote:
On 14-05-2012 21:51, Steven Schveighoffer wrote:
It also should be recommended that the scratch space not contain any GC
pointers, since it's *not* participating in the type syste
On Mon, 14 May 2012 15:56:37 -0400, Alex Rønne Petersen
wrote:
On 14-05-2012 21:51, Steven Schveighoffer wrote:
It also should be recommended that the scratch space not contain any GC
pointers, since it's *not* participating in the type system properly,
the GC may not treat it as a pointer.
On 14.05.2012 23:51, Steven Schveighoffer wrote:
I have an idea on how to create logical const without any language or
compiler changes -- it will exist purely in druntime.
The idea is based on this: Whenever you allocate an object, you use a
memory block. An object, by default, has the
On Mon, May 14, 2012 at 03:51:09PM -0400, Steven Schveighoffer wrote:
> I have an idea on how to create logical const without any language
> or compiler changes -- it will exist purely in druntime.
[...]
> In essence, a const(MyObj) is a pointer to a struct that looks like:
&g
On 14-05-2012 21:51, Steven Schveighoffer wrote:
I have an idea on how to create logical const without any language or
compiler changes -- it will exist purely in druntime.
The idea is based on this: Whenever you allocate an object, you use a
memory block. An object, by default, has the
I have an idea on how to create logical const without any language or
compiler changes -- it will exist purely in druntime.
The idea is based on this: Whenever you allocate an object, you use a
memory block. An object, by default, has the following memory layout:
monitor - (void
"Steven Schveighoffer" , dans le message (digitalmars.D:145867), a
écrit :
> But ref int _i is the parameter to the constructor. Here is where your
> proposal breaks down.
>
> It's entirely feasible for class Foo to be compiled *separately* from the
> module that contains globalFoo. And it'
On Fri, 30 Sep 2011 14:51:19 -0400, Christophe
wrote:
"Steven Schveighoffer" , dans le message (digitalmars.D:145850), a
This also doesn't work:
Indeed. The compiler should not allow the implicit conversion of
globalFoo to immutable.
class Foo
{
this(ref int _i) { dg = () { return _
"Steven Schveighoffer" , dans le message (digitalmars.D:145850), a
> As long as you assume the context pointer is part of the state of the
> aggregate, then yes. But I don't see it that way. The context pointer is
> part of the state of the delegate, and the delegate reference itself is
> t
On 2011-09-30 18:07:54 +, "Steven Schveighoffer"
said:
On Fri, 30 Sep 2011 14:00:36 -0400, Michel Fortin
wrote:
Interesting proposal. You realize if we had a true 'mutable' storage
class for class members it could obey the same rule as you propose in
that bug report: it should be i
eresting way to make a logical const object
without casts. It requires a little extra storage, but works
without changes to the current compiler (and requires no casts).
Here's the code, then I'll talk about the implications:
import std.stdio;
class D
{
D getme()
On 2011-09-30 17:46:13 +, "Steven Schveighoffer"
said:
On Fri, 30 Sep 2011 13:38:31 -0400, Michel Fortin
wrote:
On 2011-09-29 14:54:24 +, "Steven Schveighoffer"
said:
I just thought of an interesting way to make a logical const object
without casts.
On Fri, 30 Sep 2011 13:46:13 -0400, Steven Schveighoffer
wrote:
Simen Kjaeraas and Christophe brought up the same points. I filed a bug
on it:
http://d.puremagic.com/issues/show_bug.cgi?id=6741
Also now:
http://d.puremagic.com/issues/show_bug.cgi?id=6747
-Steve
On Fri, 30 Sep 2011 13:38:31 -0400, Michel Fortin
wrote:
On 2011-09-29 14:54:24 +, "Steven Schveighoffer"
said:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to t
On Fri, 30 Sep 2011 12:16:03 -0400, Christophe
wrote:
"Steven Schveighoffer" , dans le message (digitalmars.D:145821), a
écrit :
If const must be a part of the signature, then you have lost the
typeless
aspect of the context pointer. If we expose the const (or not const)
nature of the po
On 2011-09-29 14:54:24 +, "Steven Schveighoffer"
said:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
Here's the code,
Am 29.09.2011, 16:54 Uhr, schrieb Steven Schveighoffer
:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
Here's the code, then I
"Steven Schveighoffer" , dans le message (digitalmars.D:145821), a
écrit :
> If const must be a part of the signature, then you have lost the typeless
> aspect of the context pointer. If we expose the const (or not const)
> nature of the pointer, then you lose the interoperability that delega
1 16:54:24 +0200, Steven Schveighoffer
wrote:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
[snip]
What do people think about this?
This is what I t
54:24 +0200, Steven Schveighoffer
>>> wrote:
>>>
>>>> I just thought of an interesting way to make a logical const object
>>>> without casts. It requires a little extra storage, but works without
>>>> changes to the current compiler (and req
On Thu, 29 Sep 2011 13:26:11 -0400, Steven Schveighoffer
wrote:
On Thu, 29 Sep 2011 13:06:55 -0400, Simen Kjaeraas
wrote:
On Thu, 29 Sep 2011 16:54:24 +0200, Steven Schveighoffer
wrote:
I just thought of an interesting way to make a logical const object
without casts. It requires
On Thu, 29 Sep 2011 13:06:55 -0400, Simen Kjaeraas
wrote:
On Thu, 29 Sep 2011 16:54:24 +0200, Steven Schveighoffer
wrote:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current
On Thu, 29 Sep 2011 16:54:24 +0200, Steven Schveighoffer
wrote:
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
[snip]
What do people think
I just thought of an interesting way to make a logical const object
without casts. It requires a little extra storage, but works without
changes to the current compiler (and requires no casts).
Here's the code, then I'll talk about the implications:
import std.stdio;
class D
{
On 03/12/2010 23:09, Fawzi Mohamed wrote:
On 3-dic-10, at 17:23, Bruno Medeiros wrote:
On 03/12/2010 13:22, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
wrote:
The above are not trivial differences, so I do not agree that it
constitutes full logical const
ble data that the object would require and should
not be cleared (like the parent Widget in the other example you gave).
the mutable member is not marked as shared. It cannot be accessed on a
shared instance. I guess it should be explicitly noted that a logical
const notation (such as 'muta
On 3-dic-10, at 17:23, Bruno Medeiros wrote:
On 03/12/2010 13:22, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
wrote:
The above are not trivial differences, so I do not agree that it
constitutes full logical const, only a limited form of it. More
would require and should not be cleared (like the parent
Widget in the other example you gave).
the mutable member is not marked as shared. It cannot be accessed on a
shared instance. I guess it should be explicitly noted that a logical
const notation (such as 'mutable') would not
On 02/12/2010 09:18, Don wrote:
> Walter Bright wrote:
>> spir wrote:
>>> What would be the consequences if D had no const, only immutable
>>> (that, IIUC, removes the latter non-guarantee)?
>>
>> You'd have to write most every function twice, once to take immutable
>> args and again for mutable o
On 03/12/2010 14:03, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 08:22:01 -0500, Steven Schveighoffer
wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
wrote:
The above are not trivial differences, so I do not agree that it
constitutes full logical const, only a limited form
On 03/12/2010 13:22, Steven Schveighoffer wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
wrote:
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 i
On 03/12/2010 13:00, Bruno Medeiros wrote:
(if you manage to mutate it without casts in a pure function, it's
because of a compiler bug)
Fresh from this discussion:
http://d.puremagic.com/issues/show_bug.cgi?id=5311
--
Bruno Medeiros - Software Engineer
On Fri, 03 Dec 2010 08:22:01 -0500, Steven Schveighoffer
wrote:
On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
wrote:
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 const
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 ho
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'
, 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.
. 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
Steven Schveighoffer wrote:
I have shown examples of how const does not guarantee an object's state
doesn't change.
Yes, as is well documented, const is a read only view. It is not immutable. That
is why immutable is a separate attribute.
ready 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 wa
Don Wrote:
> Jonathan M Davis wrote:
> > On Thursday, December 02, 2010 01:18:31 Don wrote:
> >> Walter Bright wrote:
> >>> spir wrote:
> What would be the consequences if D had no const, only immutable
> (that, IIUC, removes the latter non-guarantee)?
> >>> You'd have to write most ever
On Thu, 02 Dec 2010 13:57:04 -0500, Bruno Medeiros
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
ees something very focused, and possible to work around without
resorting to unsafe code. That's my point. The guarantee is well-defined
and useful because it helps write correct code, but I don't see how a
logical const guarantee is mythical whereas D's current const guarantee
ould store some data in a global variable, possibly even uniquely
associated with each instance (I have shown this in a very old post
proving logical const == const). Then logically, the author of C could
consider that data a part of C. I have no way to stop him from editing
that logical
On Thu, 02 Dec 2010 15:25:49 -0500, Don wrote:
Jonathan M Davis wrote:
On Thursday, December 02, 2010 01:18:31 Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write mo
Jonathan M Davis wrote:
On Thursday, December 02, 2010 01:18:31 Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
ar
Don wrote:
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
args and again for mutable ones.
Doesn't 'inout' do almost the
them...
Surely I'm not the only person that finds something *incredibly* wrong
with this!?
Indeed, you should not try to use D's const for the use-case of logical
const. Rather, logical const is simply not supported, on a static type
level.
But why is that such a big problem act
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
On 29/11/2010 23:04, Walter Bright wrote:
Steven Schveighoffer wrote:
On Mon, 29 Nov 2010 15:58:10 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
Having a logical const feature in D would not be a convention, it
would be enforced, as much as const is enforced. I don't under
On Thursday, December 02, 2010 01:18:31 Don wrote:
> Walter Bright wrote:
> > spir wrote:
> >> What would be the consequences if D had no const, only immutable
> >> (that, IIUC, removes the latter non-guarantee)?
> >
> > You'd have to write most every function twice, once to take immutable
> > arg
On 01/12/2010 21:09, Steven Schveighoffer wrote:
On Tue, 30 Nov 2010 16:53:14 -0500, Walter Bright
wrote:
Steven Schveighoffer wrote:
If you find the above unsurprising, you are in the minority. I find
it surprising, and invalid that anyone would write code this way.
People simply just don't
relationship outside
the widget. Since each widget has exactly one location where it
lives, this is awkward. Much better to just store the relationship
on each widget.
indeed that is one of the main things that I want from logical const:
being able to store/memoize values in a structure, not
ready, not with a thread lock) in
https://github.com/fawzi/blip/blob/master/blip/parallel/smp/DataFlowVar.d
using D1
I've taken many example use-cases for logical const and added them
as unittests. I think it is fairly reasonable if I could just get an
answer to my question a
Walter Bright wrote:
spir wrote:
What would be the consequences if D had no const, only immutable
(that, IIUC, removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable
args and again for mutable ones.
Doesn't 'inout' do almost the same thing?
n uniquely
associated with each instance (I have shown this in a very old post
proving logical const == const). Then logically, the author of C could
consider that data a part of C. I have no way to stop him from editing
that logical part of C, I'm relying on the author of C not to count
mutable s
2. Why does Widget have a draw function?
Really?
Sorry about that one, it was a misunderstanding on my part, was thinking i
removed that.
And thanks for the reply!
On Wed, 01 Dec 2010 12:43:38 -0500, Jesse Phillips
wrote:
Jordi Wrote:
On the other side, in D, it is a hint to the compiler but it will only
use it if is verifiable. If that is the case, why do we need the "const"
keyword in the first place? The compiler can already verify that the
code is
On Wed, 01 Dec 2010 11:49:36 -0500, so wrote:
On Wed, 01 Dec 2010 18:38:23 +0200, so wrote:
Since i called it a bad design, i am entitled to introduce a better
design.
interface renderer {
void draw(rect rects, size_t n);
}
class widget {
void draw(renderer r) { ... }
}
On Wed, 01 Dec 2010 11:09:08 -0500, so wrote:
Most likely not. How do you say that the 'draw' function switches the
widget to a different parameterized type? With const, you can just
slap a const on the end of the function.
Here is some example of what I mean:
class Widget
{
mutable
uely associated
with each instance (I have shown this in a very old post proving logical
const == const). Then logically, the author of C could consider that data
a part of C. I have no way to stop him from editing that logical part of
C, I'm relying on the author of C not to count mutab
so Wrote:
> One another thing i don't quite get is why cast from immutable/const is
> allowed.
> Is it because of the cases that we know the function doesn't change
> anything but still lacks the immutable/const signature?
>
> Thank you!
I believe it is because cast doesn't do any checking.
Jonathan M Davis wrote:
Also, a classic example for the use of const which immutable doesn't help you
with it all is returning member variables by reference or which are reference
types when you don't want the caller to be able to modify them. Without const,
you couldn't do that. const is huge.
spir wrote:
What would be the consequences if D had no const, only immutable (that, IIUC,
removes the latter non-guarantee)?
You'd have to write most every function twice, once to take immutable args and
again for mutable ones.
On Wednesday, December 01, 2010 06:17:56 spir wrote:
> On Wed, 1 Dec 2010 03:22:39 -0800
>
> Jonathan M Davis wrote:
> > > What would be the consequences if D had no const, only immutable (that,
> > > IIUC, removes the latter non-guarantee)?
> >
> > The biggest problem would be that no function
fy
things you claimed could be modified. But it can't enforce that it is logically
const. It could prevent the modifiable parts from influencing the result, but
then the requested caching isn't possible.
> Please let me know if i wrote something that doesn't make sense.
>
> Jo
On Wed, 01 Dec 2010 18:38:23 +0200, so wrote:
Since i called it a bad design, i am entitled to introduce a better
design.
interface renderer {
void draw(rect rects, size_t n);
}
class widget {
void draw(renderer r) { ... }
}
Pfft sorry for that abomination!
interface rend
Since i called it a bad design, i am entitled to introduce a better design.
interface renderer {
void draw(rect rects, size_t n);
}
class widget {
void draw(renderer r) { ... }
}
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Most likely not. How do you say that the 'draw' function switches the
widget to a different parameterized type? With const, you can just slap
a const on the end of the function.
Here is some example of what I mean:
class Widget
{
mutable Window location;
int x, y, width, height;
On 11/29/2010 11:56 PM, Steven Schveighoffer wrote:
On Sat, 20 Nov 2010 09:21:04 -0500, Peter Alexander
wrote:
D does not support logical const due to the weak guarantees that it
provides.
So, without logical const, how are D users supposed to provide lazy
evaluation and memoization in their
1 - 100 of 220 matches
Mail list logo