Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on everything.
opEquals() is in conflict with this, since it is a member function of
Object.
(1) If it is a const member function, then it will have a viral effe
On Thursday 10 February 2011 00:19:38 Don wrote:
> Andrei once stated a worthy goal: as far as possible, const should be
> opt-in: it should be possible to code without requiring const on
> everything.
>
> opEquals() is in conflict with this, since it is a member function of
> Object.
>
> (1) If
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a member function of
Object.
(1) If it is a const member function,
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be marked
const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
unless we also state that every function in Object
Saying that no one should have to worry about const if they don't want
to is a
noble though, I suppose, but I don't think that it's entirely realistic.
const
is part of the language, and some things just plain have to be const to
work.
And given the prevalence of immutable with regards to thr
On Thursday 10 February 2011 01:26:14 so wrote:
> > Saying that no one should have to worry about const if they don't want
> > to is a
> > noble though, I suppose, but I don't think that it's entirely realistic.
> > const
> > is part of the language, and some things just plain have to be const to
>
so wrote:
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be
marked const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
unless we also state that every function in
On Thursday 10 February 2011 01:36:56 Don wrote:
> so wrote:
> >> (1) If it is a const member function, then it will have a viral effect
> >> on all objects -- any function called by opEquals will have to be
> >> marked const.
> >
> > It doesn't look like we can solve this by switching the constne
Can you think of a use case where the calling function should know that
opEquals() isn't truly const?
I can't think of any.
If we are going to this way, we need all four of them to be const i think.
On Thu, 10 Feb 2011 10:58:25 +0200, Peter Alexander
wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a me
On 2011-02-10 04:36:56 -0500, Don said:
so wrote:
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be
marked const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
On Thu, 10 Feb 2011 03:37:58 -0500, Jonathan M Davis
wrote:
On Thursday 10 February 2011 00:19:38 Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this
Don Wrote:
> Andrei once stated a worthy goal: as far as possible, const should be
> opt-in: it should be possible to code without requiring const on everything.
>
> opEquals() is in conflict with this, since it is a member function of
> Object.
>
> (1) If it is a const member function, then i
On 02/10/2011 10:09 AM, so wrote:
(1) If it is a const member function, then it will have a viral effect on all
objects -- any function called by opEquals will have to be marked const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
Is this point very
On 02/10/2011 10:26 AM, so wrote:
Saying that no one should have to worry about const if they don't want to is a
noble though, I suppose, but I don't think that it's entirely realistic. const
is part of the language, and some things just plain have to be const to work.
And given the prevalence of
On Thu, 10 Feb 2011 09:15:36 -0500, Jason House
wrote:
Don Wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a member function of
Obje
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a member function of
Obj
On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
wrote:
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEqu
Steven Schveighoffer Wrote:
> On Thu, 10 Feb 2011 09:15:36 -0500, Jason House
> wrote:
>
> > Don Wrote:
> >
> >> Andrei once stated a worthy goal: as far as possible, const should be
> >> opt-in: it should be possible to code without requiring const on
> >> everything.
> >>
> >> opEquals() i
On Thu, 10 Feb 2011 12:24:02 -0500, Jason House
wrote:
Steven Schveighoffer Wrote:
On Thu, 10 Feb 2011 09:15:36 -0500, Jason House
wrote:
> Don Wrote:
>
>> Andrei once stated a worthy goal: as far as possible, const should be
>> opt-in: it should be possible to code without requiring cons
On Thu, 10 Feb 2011 13:59:24 -0500, Steven Schveighoffer
wrote:
No but you can make things easier to avoid writing incorrect code. This
kind of change invites mistakes, because it looks like you have to
completely duplicate your logic, and forgetting to modify one and not
the other happ
Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
wrote:
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring
On Thu, 10 Feb 2011 15:22:48 -0500, Don wrote:
A tiny compromise which could be made, is to silently add 'const' to any
class opEquals declaration, even if not present in the source. That way,
simple use cases would still compile without complaint.
(As long as only a single, precisely define
On Thursday 10 February 2011 12:22:48 Don wrote:
> Steven Schveighoffer wrote:
> > On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
> >
> > wrote:
> >> On 2/10/11 2:58 AM, Peter Alexander wrote:
> >>> On 10/02/11 8:19 AM, Don wrote:
> Andrei once stated a worthy goal: as far as possib
Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 15:22:48 -0500, Don wrote:
A tiny compromise which could be made, is to silently add 'const' to
any class opEquals declaration, even if not present in the source.
That way, simple use cases would still compile without complaint.
(As long as only
On 2/10/11 9:33 AM, Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
wrote:
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to cod
On 2011-02-10 15:22:48 -0500, Don said:
Steven Schveighoffer wrote:
This doesn't work. If you only define one, then you will have problems
with hidden function errors, and/or inconsistencies. For example, how
does .opEquals(Object obj1, Object obj2) know which version to call?
I think the
Has it been considered for constness or such constraints not to be
inherited? (Rather plain functype signature.)
Denis
I asked something similar not more than a week ago,
it is possible in theory i think but implementation is very problematic
and requires a big shift in the meaning of const
On Thu, 10 Feb 2011 16:34:57 -0500, Don wrote:
Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 15:22:48 -0500, Don wrote:
A tiny compromise which could be made, is to silently add 'const' to
any class opEquals declaration, even if not present in the source.
That way, simple use cases wou
Michel Fortin wrote:
On 2011-02-10 15:22:48 -0500, Don said:
Steven Schveighoffer wrote:
This doesn't work. If you only define one, then you will have
problems with hidden function errors, and/or inconsistencies. For
example, how does .opEquals(Object obj1, Object obj2) know which
version
On 02/11/2011 12:20 AM, Don wrote:
I don't like this idea at all. If the problem is that it's too easy to hide
the underlying function without noticing (no compile-time error), then fix
how the language treats hidden functions (make it a compile-time error). If
opEquals has this problem, other no
This isn't really true. If you make opEquals const, then anything
opEquals calls must be const. Inevitably, you need to make a lot of
your object const, which then goes viral to things that object uses, etc.
On the other hand, I don't think opt-in const is that worthy a goal.
Things that
Vote++
--
Graham St Jack
We _must_ have it there, so anyone overriding those functions _must_
use it for those functions. They could create non-const versions in
addition to
the const ones,
It is the whole point, they can't.
but they _must_ create the const versions. They're stuck.
There's no way around it without b
On Thursday 10 February 2011 21:50:45 so wrote:
> > We _must_ have it there, so anyone overriding those functions _must_
> > use it for those functions. They could create non-const versions in
> > addition to
> > the const ones,
>
> It is the whole point, they can't.
Hmm. You're right (I just tri
On 02/11/2011 07:13 AM, Jonathan M Davis wrote:
We _must_ have it there, so anyone overriding those functions _must_
> > use it for those functions. They could create non-const versions in
> > addition to
> > the const ones,
>
> It is the whole point, they can't.
Hmm. You're right (I jus
On Friday 11 February 2011 02:43:11 spir wrote:
> On 02/11/2011 07:13 AM, Jonathan M Davis wrote:
> >>> We _must_ have it there, so anyone overriding those functions _must_
> >>>
> >>> > > use it for those functions. They could create non-const versions
> >>> > > in addition to
> >>> > > the
On 10/02/2011 09:36, Don wrote:
so wrote:
(1) If it is a const member function, then it will have a viral
effect on all objects -- any function called by opEquals will have to
be marked const.
It doesn't look like we can solve this by switching the constness of
an Object.function,
unless we al
Bruno Medeiros:
> The good news is that I suspect the fields used for
> opEquals/opCmp/opHash in any class are unlikely to be fields that are
> computed lazily. It's just a guess though, anyone have examples otherwise?
If I have a string type, I'd like to compute its hash value lazily, the firs
On 23/02/2011 17:50, bearophile wrote:
Bruno Medeiros:
The good news is that I suspect the fields used for
opEquals/opCmp/opHash in any class are unlikely to be fields that are
computed lazily. It's just a guess though, anyone have examples otherwise?
If I have a string type, I'd like to comp
40 matches
Mail list logo
