== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
Steven Schveighoffer wrote:
Hopefully, Andrei will eventually get around to dealing with const in
std.container and see what a mess it will become without some sort of
tail-const for ranges.
I believe at some point
dsimcha:
Are you sure std.traits.Unqual doesn't do what you want? It shallowly removes
const/immutable/shared. For example:
Sorry for the late reply.
Unqual removes all qualifiers, but I'd like something that removes just
const/immutable, and keeps all the other things.
Bye,
bearophile
Where can I read about this type system proposal you speak of?
2010/8/13 Tomek Sowiński j...@ask.me
dsimcha napisał:
1. It's difficult to create non-trivial immutable data structures, and
often impossible without relying on either unchecked casts or unnecessary
copying.
Yes. I think
Dnia 19-08-2010 o 20:02:58 Andrej Mitrovic andrej.mitrov...@gmail.com
napisał(a):
Where can I read about this type system proposal you speak of?
On his blog. On 'unique':
http://bartoszmilewski.wordpress.com/2009/05/21/unique_ptr-how-unique-is-it/
Thanks.
2010/8/20 Tomek Sowiński j...@ask.me:
Dnia 19-08-2010 o 20:02:58 Andrej Mitrovic andrej.mitrov...@gmail.com
napisał(a):
Where can I read about this type system proposal you speak of?
On his blog. On 'unique':
On 08/17/2010 01:44 AM, Steven Schveighoffer wrote:
On Mon, 16 Aug 2010 19:06:56 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
Uhm, it works in D:
class C {}
class D : C {}
void main( ) {
D[] a;
C[] b = a;
}
Yes, I was about to say that except that is a bug kind of. The type
system
On Tue, 17 Aug 2010 12:05:55 +0200, Pelle wrote:
class C { }
class D : C { }
class E : C { }
void append_to(ref const(C)[] cs, const(C) c) { cs ~= c; }
D[] ds;
append_to(ds, new E);
*ahem*
D[] can not be converted to const(C). That it works today is pretty
terrible. Rewrite the
Am 17.08.2010 12:05, schrieb Pelle:
On 08/17/2010 01:44 AM, Steven Schveighoffer wrote:
On Mon, 16 Aug 2010 19:06:56 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
Uhm, it works in D:
class C {}
class D : C {}
void main( ) {
D[] a;
C[] b = a;
}
Yes, I was about to say that except that
On Tue, 17 Aug 2010 06:05:55 -0400, Pelle pelle.mans...@gmail.com wrote:
On 08/17/2010 01:44 AM, Steven Schveighoffer wrote:
On Mon, 16 Aug 2010 19:06:56 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
Uhm, it works in D:
class C {}
class D : C {}
void main( ) {
D[] a;
C[] b = a;
}
Am 17.08.2010 13:48, schrieb Mafi:
Am 17.08.2010 12:05, schrieb Pelle:
On 08/17/2010 01:44 AM, Steven Schveighoffer wrote:
On Mon, 16 Aug 2010 19:06:56 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
Uhm, it works in D:
class C {}
class D : C {}
void main( ) {
D[] a;
C[] b = a;
}
Yes,
On 08/17/2010 02:48 PM, Steven Schveighoffer wrote:
On Tue, 17 Aug 2010 06:05:55 -0400, Pelle pelle.mans...@gmail.com wrote:
On 08/17/2010 01:44 AM, Steven Schveighoffer wrote:
On Mon, 16 Aug 2010 19:06:56 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
Uhm, it works in D:
class C {}
On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 08/13/2010 06:35 PM, Walter Bright wrote:
Steven Schveighoffer wrote:
I like how it reads naturally. I think it's also syntactically
unambiguous. Walter, please give this one some attention, I'd
On Fri, 13 Aug 2010 19:30:46 -0400, dsimcha dsim...@yahoo.com wrote:
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Friday, August 13, 2010 15:03:07 Tomek Sowiński wrote:
I agree with the content, but not the tone. D's const makes all other
mainstream const systems look
On Mon, 16 Aug 2010 01:39:21 -0400, Kagamin s...@here.lot wrote:
Steven Schveighoffer Wrote:
Syntactical. There is no way to separate the reference from the data,
since the reference is a hidden artifact of the type system.
Do you assert that there's only one possible syntax to express the
On 2010-08-16 08:08:21 -0400, Steven Schveighoffer
schvei...@yahoo.com said:
On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 08/13/2010 06:35 PM, Walter Bright wrote:
Steven Schveighoffer wrote:
I like how it reads naturally. I think it's
On Mon, 16 Aug 2010 08:56:51 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2010-08-16 08:08:21 -0400, Steven Schveighoffer
schvei...@yahoo.com said:
On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 08/13/2010 06:35 PM, Walter
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
On Fri, 13 Aug 2010 19:30:46 -0400, dsimcha dsim...@yahoo.com wrote:
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Friday, August 13, 2010 15:03:07 Tomek Sowiński wrote:
I agree with the content, but
On Mon, 16 Aug 2010 09:26:55 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2010-08-16 09:08:30 -0400, Steven Schveighoffer
schvei...@yahoo.com said:
On Mon, 16 Aug 2010 08:56:51 -0400, Michel Fortin
michel.for...@michelf.com wrote:
The idea's not bad, but I think it needs
On Mon, 16 Aug 2010 09:11:20 -0400, dsimcha dsim...@yahoo.com wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
There are other reasons to have tail-const other than classes. For
example, there's no equivalent custom-range idiom for const(T)[]. You
simply can't make a
On 2010-08-16 10:03:58 -0400, Steven Schveighoffer
schvei...@yahoo.com said:
On Mon, 16 Aug 2010 09:26:55 -0400, Michel Fortin
michel.for...@michelf.com wrote:
I think what you want for that is to somehow make SmartPtr!(X)
implicitly derived from SmartPtr!(const X), you don't want the
Steven Schveighoffer wrote:
Hopefully, Andrei will eventually get around to dealing with const in
std.container and see what a mess it will become without some sort of
tail-const for ranges.
I believe at some point an approach will come forth. Here are a few
quick thoughts on this large
On Mon, 16 Aug 2010 11:00:21 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Steven Schveighoffer wrote:
On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 08/13/2010 06:35 PM, Walter Bright wrote:
Steven Schveighoffer wrote:
On Mon, 16 Aug 2010 10:58:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Steven Schveighoffer wrote:
Hopefully, Andrei will eventually get around to dealing with const in
std.container and see what a mess it will become without some sort of
tail-const for ranges.
I
On 2010-08-16 11:17:32 -0400, Steven Schveighoffer
schvei...@yahoo.com said:
struct Array(V)
{
uint length;
V *v;
}
How can we turn Array!V into Array!(const(V)) implicitly...
Shouldn't this work?
struct Array(V) {
uint length;
V *v;
On 2010-08-16 11:23:24 -0400, Michel Fortin michel.for...@michelf.com said:
Shouldn't this work?
struct Array(V) {
uint length;
V *v;
Array!(const V) _const() @property { ... }
alias _const this;
}
Well, it
On Mon, 16 Aug 2010 10:50:04 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2010-08-16 10:03:58 -0400, Steven Schveighoffer
schvei...@yahoo.com said:
On Mon, 16 Aug 2010 09:26:55 -0400, Michel Fortin
michel.for...@michelf.com wrote:
I think what you want for that is to
On Mon, 16 Aug 2010 11:30:10 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2010-08-16 11:23:24 -0400, Michel Fortin michel.for...@michelf.com
said:
Shouldn't this work?
struct Array(V) {
uint length;
V *v;
Array!(const V)
On 2010-08-16 11:39:15 -0400, Steven Schveighoffer
schvei...@yahoo.com said:
Translating it to your example, should you be able to convert from a
const(SmartPointer!X) to a SmartPointer!(const X) ? I'd say no,
because const(SmartPointer!X) guarantees that the refCount will not
change.
Michel Fortin wrote:
We're reinventing static-inheritance using alias this.
Static this has been from the get-go the intent to achieve subtyping for
structs. I, too, think that a solution to tail const for ranges should
gravitate around alias this.
Andrei
On Mon, 16 Aug 2010 18:12:35 -0400, Tomek Sowiński j...@ask.me wrote:
Dnia 16-08-2010 o 17:17:32 Steven Schveighoffer schvei...@yahoo.com
napisał(a):
* Perhaps a good starting point is to look at std.container.SList and
see how const(SList!T) can be manipulated.
We can start simpler than
Jonathan M Davis jmdavisp...@gmail.com wrote:
On Monday, August 16, 2010 15:31:23 Steven Schveighoffer wrote:
We can move onto the next test:
Given:
class C {}
class D : C {}
convert Array!D into Array!(const C)
OK, maybe this is a more advanced test :)
I'd be happy with just proper
On 2010-08-16 19:06:56 -0400, Simen kjaeraas simen.kja...@gmail.com said:
Uhm, it works in D:
class C {}
class D : C {}
void main( ) {
D[] a;
C[] b = a;
}
Then that's a bug because it'd allow you to do this:
void main() {
D[] a = new D[1];
On 14/08/10 14:39, Denis Koroskin wrote:
Graham St Jack Wrote:
For me, the key problem is that a class object reference has the same
const/immutable/shared attribute as the object on the heap that it
refers to. This is sometimes what you need, but more often you want a
non-shared, mutable
dsimcha:
I've added some trivial convenience functions to Phobos that should have been
there a long time ago and should go a long way towards making Rebindable more
usable. The other thing we need is bug fixes in alias this/opDot, which we
need
eventually anyhow. Now, instead of doing
Kagamin:
Ah, and many casts to object and from object. This caused many bugs. That's
why I will always advocate for throwing cast, it's unacceptable that D by
default provides bug-prone behavior. I will never accept this.
This deserves to be thought about.
Bye,
bearophile
Steven Schveighoffer Wrote:
Syntactical. There is no way to separate the reference from the data,
since the reference is a hidden artifact of the type system.
Do you assert that there's only one possible syntax to express the type system?
Adam Ruppe Wrote:
On the subject of rebindable, what about:
const Object o; // not rebindable, the whole thing is set once and const
const(Object) o; // the Object is const, but the reference is not.
So, everything is rebindable unless the declaration has a
const/immutable on the
Jonathan M Davis Wrote:
You can obviously do lots of quality programs without const, but having it is
a
big plus.
We do have evil developers that write evil code, my point is that nevertheless
the lack of constness didn't cause bugs. The constness in D2 did help me only
to comply with OS
Michel Fortin michel.for...@michelf.com wrote:
Object o; // implicitly a reference
Object ref o; // explicit reference marker
Both would be allowed and equivalent. While the first form is nicer to
the eye, the second makes it easy to apply a type modifier while
excluding
Nick Sabalausky wrote:
Justin Johansson n...@spam.com wrote in message
news:i42ba3$1b...@digitalmars.com...
Nick Sabalausky wrote:
Justin Johansson n...@spam.com wrote in message
news:i424ac$27n...@digitalmars.com...
Graham St Jack wrote:
Is there any plan to introduce some way of having a
On 2010-08-13 01:10:20 -0400, Kagamin s...@here.lot said:
Jonathan M Davis Wrote:
The lack of a mutable qualifier seems like it could be
another big problem, but I haven't yet written enough code in D to run
into that
issue (still I'm sure I'll run into it eventually and be highly annoyed -
On Fri, 13 Aug 2010 01:46:51 -0400, Kagamin s...@here.lot wrote:
Walter Bright Wrote:
Graham St Jack wrote:
However, I still regard the language design decision of a class
reference having the same constness as the object it refers to as a
major language design problem.
We tried for
On Thu, 12 Aug 2010 21:45:16 -0400, Jonathan M Davis
jmdavisp...@gmail.com wrote:
On Thursday, August 12, 2010 18:16:01 Graham St Jack wrote:
On 13/08/10 10:18, Jonathan M Davis wrote:
On Thursday, August 12, 2010 17:38:28 Graham St Jack wrote:
For me, the key problem is that a class
On Thu, 12 Aug 2010 21:37:11 -0400, Jonathan M Davis
jmdavisp...@gmail.com wrote:
2. The shear difficulty in getting in getting immutable versions of
stuff. There is
no automated way to do it other than idup with arrays.
Note that idup and dup are broken wrt const:
On Thu, 12 Aug 2010 22:23:30 -0400, Adam Ruppe destructiona...@gmail.com
wrote:
On the subject of rebindable, what about:
const Object o; // not rebindable, the whole thing is set once and const
const(Object) o; // the Object is const, but the reference is not.
So, everything is rebindable
On Fri, 13 Aug 2010 09:32:49 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 13 Aug 2010 01:46:51 -0400, Kagamin s...@here.lot wrote:
Walter Bright Wrote:
Graham St Jack wrote:
However, I still regard the language design decision of a class
reference having the same
On Thu, 12 Aug 2010 22:09:51 -0400, Michel Fortin
michel.for...@michelf.com wrote:
On 2010-08-12 18:56:50 -0400, dsimcha dsim...@yahoo.com said:
How can these limitations be worked around and/or fixed?
Unsatisfaction about Rebindable seems pretty generalized.
Here's an idea for a
Graham St Jack napisał:
The major language hassle for me is that a class reference has the same
const/immutable/shared type as the object is refers to, unlike pointers.
I know that Rebindable is a workaround, but I don't find it satisfactory
- essentially it uses brute-force casting to defeat
On Fri, 13 Aug 2010 15:46:30 -0400, Tomek Sowiński j...@ask.me wrote:
Graham St Jack napisał:
The major language hassle for me is that a class reference has the same
const/immutable/shared type as the object is refers to, unlike pointers.
I know that Rebindable is a workaround, but I don't
dsimcha napisał:
1. It's difficult to create non-trivial immutable data structures, and
often impossible without relying on either unchecked casts or unnecessary
copying.
Yes. I think the only true solution is 'unique' in the language. This is my
most wanted from Bartosz's type system
Graham St Jack wrote:
For me, the key problem is that a class object reference has the same
const/immutable/shared attribute as the object on the heap that it
refers to. This is sometimes what you need, but more often you want a
non-shared, mutable reference to a const/immutable/shared object.
Jonathan M Davis wrote:
That is, unfortunately, a very good point. It's still seriously limiting,
however. What it means is that there is going to be code out there (and possibly
a lot of it) which _should_ be const but can't be.
I presume you're talking about logical constness, for data
On Friday, August 13, 2010 13:37:09 Walter Bright wrote:
There are many languages which support immutable - but it's hidden away in
how they handle strings. For example, Perl has immutable strings.
The great advantage to immutability (aside from threading) is that you can
treat a reference
Steven Schveighoffer napisał:
On Fri, 13 Aug 2010 15:46:30 -0400, Tomek Sowiński j...@ask.me wrote:
I see it as a huge problem too. Crazy idea: introduce @tail to be used
in combo with const/immutable. I'd find it even useful on structs.
@tail immutable struct Ref {
int[] array;
On Friday, August 13, 2010 14:10:20 Tomek Sowiński wrote:
Glad you like it. Time ago I had an overzealous attempt to port QuantLib to
D and I quickly found out that the *only* sort of const I needed was tail
const. It's what I ended up declaring fields of my structs because if just
one field
Jonathan M Davis napisał:
On Friday, August 13, 2010 14:10:20 Tomek Sowiński wrote:
Glad you like it. Time ago I had an overzealous attempt to port QuantLib
to D and I quickly found out that the *only* sort of const I needed was
tail const. It's what I ended up declaring fields of my structs
On Friday, August 13, 2010 15:03:07 Tomek Sowiński wrote:
I agree with the content, but not the tone. D's const makes all other
mainstream const systems look petty. Applying the concept of transitivity
has been revolutionary (hail Walter). Tail const is just a cable to the
socket to make this
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Friday, August 13, 2010 15:03:07 Tomek Sowiński wrote:
I agree with the content, but not the tone. D's const makes all other
mainstream const systems look petty. Applying the concept of transitivity
has been revolutionary
Steven Schveighoffer wrote:
I like how it reads naturally. I think it's also syntactically
unambiguous. Walter, please give this one some attention, I'd love to
see this fixed.
This was endlessly discussed maybe 3 years ago. I probably invested over a
hundred hours in trying to make it
On 14/08/10 05:55, Walter Bright wrote:
Graham St Jack wrote:
For me, the key problem is that a class object reference has the same
const/immutable/shared attribute as the object on the heap that it
refers to. This is sometimes what you need, but more often you want a
non-shared, mutable
On Friday, August 13, 2010 16:30:46 dsimcha wrote:
I still don't understand: What's so bad about Rebindable? Yes, it's not
the syntactically prettiest thing in the world, but complaining about it
is like complaining about climbing a molehill when you've got Mount
Everest to climb next. My
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Friday, August 13, 2010 16:30:46 dsimcha wrote:
I still don't understand: What's so bad about Rebindable? Yes, it's not
the syntactically prettiest thing in the world, but complaining about it
is like complaining about
Walter Bright napisał:
But there is a solution:
const(Object)* o;
Interesting. How do you cook that with polymorphism? This doesn't work:
interface I { }
class A : I {}
void main() {
immutable A a = new immutable(A);
immutable(A)* ap = a;
// Error: cannot implicitly convert
Tomek Sowiński wrote:
Walter Bright napisał:
But there is a solution:
const(Object)* o;
Interesting. How do you cook that with polymorphism? This doesn't work:
interface I { }
class A : I {}
void main() {
immutable A a = new immutable(A);
immutable(A)* ap = a;
// Error: cannot
Tomek Sowiński, el 14 de agosto a las 02:52 me escribiste:
Walter Bright napisał:
But there is a solution:
const(Object)* o;
Interesting. How do you cook that with polymorphism? This doesn't work:
interface I { }
class A : I {}
void main() {
immutable A a = new
On 2010-08-13 20:45:13 -0400, dsimcha dsim...@yahoo.com said:
http://dsource.org/projects/phobos/changeset/1849
I've added some trivial convenience functions to Phobos that should have been
there a long time ago and should go a long way towards making Rebindable more
usable. The other thing
On 08/13/2010 06:35 PM, Walter Bright wrote:
Steven Schveighoffer wrote:
I like how it reads naturally. I think it's also syntactically
unambiguous. Walter, please give this one some attention, I'd love to
see this fixed.
This was endlessly discussed maybe 3 years ago. I probably invested
Graham St Jack Wrote:
For me, the key problem is that a class object reference has the same
const/immutable/shared attribute as the object on the heap that it
refers to. This is sometimes what you need, but more often you want a
non-shared, mutable reference to a const/immutable/shared
This is from a discussion that originated on the Phobos mailing list, but I
thought I'd bring up the question of what should be done about const on the
newsgroup to see what others think:
Despite its theoretical beauty, I find D's const/immutable system to be
utterly useless for all but the
On Thursday, August 12, 2010 15:56:50 dsimcha wrote:
This is from a discussion that originated on the Phobos mailing list, but I
thought I'd bring up the question of what should be done about const on the
newsgroup to see what others think:
Despite its theoretical beauty, I find D's
dsimcha wrote:
This is from a discussion that originated on the Phobos mailing list, but I
thought I'd bring up the question of what should be done about const on the
newsgroup to see what others think:
Despite its theoretical beauty, I find D's const/immutable system to be
utterly useless for
Jonathan M Davis:
The lack of a mutable qualifier seems like it could be
another big problem,
I was thinking about a Deconst!() template...
Bye,
bearophile
On 2010-08-12 18:56:50 -0400, dsimcha dsim...@yahoo.com said:
It would have probably been better if this was brought to a head
sooner, but it's better late than never. Do others agree that D's
const system is difficult to impossible to use properly?
I agree. Rebindable looks like a hack, as
A few years ago I had a look at D, and I remember there were some NG posts
about broken const and such. I honestly thought whatever that was broken was
fixed by now. I haven't used D too much, so I'm yet to be affected by this.
From the looks of posts it seems to be bad though.
On Fri, Aug 13,
I have tried using const/immutable/shared several times, and am
currently in the process of giving it another shot, with much more
success that before, but it is hard work.
The major language hassle for me is that a class reference has the same
const/immutable/shared type as the object is
Well isn't it natural that a constness system has a much larger impact
than just some syntax additions.
I don't see any flaws in its design. The implementation is of course still
buggy though and needs to mature.
On Thu, 12 Aug 2010, dsimcha wrote:
This is from a discussion that originated on the Phobos mailing list, but I
thought I'd bring up the question of what should be done about const on the
newsgroup to see what others think:
Despite its theoretical beauty, I find D's const/immutable system
Jonathan M Davis wrote:
The
lack of a mutable qualifier seems like it could be another big problem,
but I haven't yet written enough code in D to run into that issue (still
I'm sure I'll run into it eventually and be highly annoyed - it's just
needed too often in C++ for me not to be happy
On 13/08/10 09:51, Brad Roberts wrote:
On Thu, 12 Aug 2010, dsimcha wrote:
This is from a discussion that originated on the Phobos mailing list, but I
thought I'd bring up the question of what should be done about const on the
newsgroup to see what others think:
Despite its theoretical
Trass3r wrote:
Well isn't it natural that a constness system has a much larger impact
than just some syntax additions.
I don't see any flaws in its design. The implementation is of course
still buggy though and needs to mature.
I agree. There are very severe bugs and undue limitations in
On 13/08/10 10:08, Andrei Alexandrescu wrote:
Trass3r wrote:
Well isn't it natural that a constness system has a much larger
impact than just some syntax additions.
I don't see any flaws in its design. The implementation is of course
still buggy though and needs to mature.
I agree. There are
== Quote from bearophile (bearophileh...@lycos.com)'s article
Jonathan M Davis:
The lack of a mutable qualifier seems like it could be
another big problem,
I was thinking about a Deconst!() template...
Bye,
bearophile
Are you sure std.traits.Unqual doesn't do what you want? It shallowly
Graham St Jack wrote:
Is there any plan to introduce some way of having a mutable reference to
an immutable class object on the heap? Do others see this as a problem
at all?
For embedded microsystems (i.e. with ROM/RAM) this is a problem. It
is a common use case to have a mutable reference
On Thursday, August 12, 2010 17:38:28 Graham St Jack wrote:
For me, the key problem is that a class object reference has the same
const/immutable/shared attribute as the object on the heap that it
refers to. This is sometimes what you need, but more often you want a
non-shared, mutable
Justin Johansson n...@spam.com wrote in message
news:i424ac$27n...@digitalmars.com...
Graham St Jack wrote:
Is there any plan to introduce some way of having a mutable reference to
an immutable class object on the heap? Do others see this as a problem at
all?
For embedded microsystems
== Quote from Brad Roberts (bra...@slice-2.puremagic.com)'s article
For discussions like this, I think it's essential to distinguish between
the language vs the runtime + core libraries. I recognize what matters is
the end result usability, but examining the layers independently is really
On 13/08/10 10:18, Jonathan M Davis wrote:
On Thursday, August 12, 2010 17:38:28 Graham St Jack wrote:
For me, the key problem is that a class object reference has the same
const/immutable/shared attribute as the object on the heap that it
refers to. This is sometimes what you need, but
On Thursday, August 12, 2010 18:12:25 dsimcha wrote:
== Quote from Brad Roberts (bra...@slice-2.puremagic.com)'s article
For discussions like this, I think it's essential to distinguish between
the language vs the runtime + core libraries. I recognize what matters
is the end result
On Thursday, August 12, 2010 18:16:01 Graham St Jack wrote:
On 13/08/10 10:18, Jonathan M Davis wrote:
On Thursday, August 12, 2010 17:38:28 Graham St Jack wrote:
For me, the key problem is that a class object reference has the same
const/immutable/shared attribute as the object on the heap
On 2010-08-12 21:37:11 -0400, Jonathan M Davis jmdavisp...@gmail.com said:
3. The lack of a mutable modifier.
There are times when you need a mutable modifier to sanely use const (it
obviously wouldn't work with immutable regardless). I don't know if there's any
way to safely do this with a
On 2010-08-12 18:56:50 -0400, dsimcha dsim...@yahoo.com said:
How can these limitations be worked around and/or fixed?
Unsatisfaction about Rebindable seems pretty generalized.
Here's an idea for a solution. Basically the problem is only in the
syntax, where the reference is implicitly part
On the subject of rebindable, what about:
const Object o; // not rebindable, the whole thing is set once and const
const(Object) o; // the Object is const, but the reference is not.
So, everything is rebindable unless the declaration has a
const/immutable on the outside.
int a; // rebindable
Nick Sabalausky wrote:
Justin Johansson n...@spam.com wrote in message
news:i424ac$27n...@digitalmars.com...
Graham St Jack wrote:
Is there any plan to introduce some way of having a mutable reference to
an immutable class object on the heap? Do others see this as a problem at
all?
For
On Thursday 12 August 2010 19:09:51 Michel Fortin wrote:
On 2010-08-12 18:56:50 -0400, dsimcha dsim...@yahoo.com said:
How can these limitations be worked around and/or fixed?
Unsatisfaction about Rebindable seems pretty generalized.
Here's an idea for a solution. Basically the problem is
On Thursday 12 August 2010 18:57:26 Michel Fortin wrote:
Const-correctness can't work the same in D as in C/C++. Even if you had
a mutable member in your class, D can't allow you to modify this member
from a const member function, because this const member function can be
called when your
Justin Johansson n...@spam.com wrote in message
news:i42ba3$1b...@digitalmars.com...
Nick Sabalausky wrote:
Justin Johansson n...@spam.com wrote in message
news:i424ac$27n...@digitalmars.com...
Graham St Jack wrote:
Is there any plan to introduce some way of having a mutable reference
to
Graham St Jack wrote:
However, I still regard the language design decision of a class
reference having the same constness as the object it refers to as a
major language design problem.
We tried for months. It just doesn't work to make it any other way than it is
now.
Jonathan M Davis Wrote:
The lack of a mutable qualifier seems like it could be
another big problem, but I haven't yet written enough code in D to run into
that
issue (still I'm sure I'll run into it eventually and be highly annoyed -
it's
just needed too often in C++ for me not to be
Kagamin Wrote:
Now I'm working on a large project written in C#. C# has only D1 const
system. Here I've seen no bugs caused by all data beign mutable. Even with
public mutable fields. Usually bugs we have are unimplemented logic,
incorrectly implemented logic, exceptions swallowing,
Walter Bright Wrote:
Graham St Jack wrote:
However, I still regard the language design decision of a class
reference having the same constness as the object it refers to as a
major language design problem.
We tried for months. It just doesn't work to make it any other way than it is
100 matches
Mail list logo
