Thread overview
[phobos] phobos commit, revision 2181
Nov 18, 2010
dsource.org
Nov 18, 2010
Shin Fujishiro
Nov 19, 2010
spir
Nov 19, 2010
spir
November 18, 2010
phobos commit, revision 2181


user: rsinfu

msg:
Constrain swap() with isMutable!T so that const objects should not be swapped. std.traits.isMutable is undocumented for now.

http://www.dsource.org/projects/phobos/changeset/2181

November 19, 2010
By the way, is it acceptable to swap structs that have const member(s)?
std.algorithm.swap() used to allow the following code:
----------
struct S
{
    const string name;
}
auto a = S("a");
auto b = S("b");

swap(a, b);
assert(a.name == "b";
assert(b.name == "a");
----------

This behavior breaks const correctness, whereas it's sometimes useful since S doesn't allow built-in assignment.  Should swap() disallow it?


Shin
November 18, 2010
That should not be accepted, so you made the right call.

Andrei

On 11/18/10 2:23 PM, Shin Fujishiro wrote:
> By the way, is it acceptable to swap structs that have const member(s)?
> std.algorithm.swap() used to allow the following code:
> ----------
> struct S
> {
>      const string name;
> }
> auto a = S("a");
> auto b = S("b");
>
> swap(a, b);
> assert(a.name == "b";
> assert(b.name == "a");
> ----------
>
> This behavior breaks const correctness, whereas it's sometimes useful since S doesn't allow built-in assignment.  Should swap() disallow it?
>
>
> Shin
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
November 19, 2010
On Thu, 18 Nov 2010 14:27:41 -0800
Andrei Alexandrescu <andrei at erdani.com> wrote:

> That should not be accepted, so you made the right call.
> 
> Andrei
> 
> On 11/18/10 2:23 PM, Shin Fujishiro wrote:
> > By the way, is it acceptable to swap structs that have const member(s)?
> > std.algorithm.swap() used to allow the following code:
> > ----------
> > struct S
> > {
> >      const string name;
> > }
> > auto a = S("a");
> > auto b = S("b");
> >
> > swap(a, b);
> > assert(a.name == "b";
> > assert(b.name == "a");
> > ----------
> >
> > This behavior breaks const correctness, whereas it's sometimes useful since S doesn't allow built-in assignment.  Should swap() disallow it?

Hum, is this really a transgression of const's promise? Each object's .name fields remains unchanged as expected. Rather only the symbolic relations (var-id <--> object) change. It's another kind of change.
Here, the 2 facts that the fields are called 'name' and that they hold values equal to var-ids, commonly called 'name' as well, just introduce confusion.
What about this, is it also inacceptable?

struct S
{
    const uint code;
}
auto a = S(1); // a <--> obj1 (code:1)
auto b = S(1); // b <--> obj2 (code:2)

swap(a, b);
assert(a.code == 2); // a <--> obj2 (code:2)
assert(b.code == 1); // b <--> obj1 (code:1)

Denis
-- -- -- -- -- -- --
vit esse estrany ?

spir.wikidot.com

November 19, 2010
On 11/19/10 2:22 AM, spir wrote:
> Hum, is this really a transgression of const's promise? Each object's .name fields remains unchanged as expected. Rather only the symbolic relations (var-id<-->  object) change. It's another kind of change.
> Here, the 2 facts that the fields are called 'name' and that they hold values equal to var-ids, commonly called 'name' as well, just introduce confusion.
> What about this, is it also inacceptable?
>
> struct S
> {
>      const uint code;
> }
> auto a = S(1); // a<-->  obj1 (code:1)
> auto b = S(1); // b<-->  obj2 (code:2)
>
> swap(a, b);
> assert(a.code == 2); // a<-->  obj2 (code:2)
> assert(b.code == 1); // b<-->  obj1 (code:1)

A const field is expected to always stay the same after being set.

Andrei
November 19, 2010
On Fri, 19 Nov 2010 09:18:47 -0800
Andrei Alexandrescu <andrei at erdani.com> wrote:

> On 11/19/10 2:22 AM, spir wrote:
> > Hum, is this really a transgression of const's promise? Each object's .name fields remains unchanged as expected. Rather only the symbolic relations (var-id<-->  object) change. It's another kind of change.
> > Here, the 2 facts that the fields are called 'name' and that they hold values equal to var-ids, commonly called 'name' as well, just introduce confusion.
> > What about this, is it also inacceptable?
> >
> > struct S
> > {
> >      const uint code;
> > }
> > auto a = S(1); // a<-->  obj1 (code:1)
> > auto b = S(1); // b<-->  obj2 (code:2)
> >
> > swap(a, b);
> > assert(a.code == 2); // a<-->  obj2 (code:2)
> > assert(b.code == 1); // b<-->  obj1 (code:1)
> 
> A const field is expected to always stay the same after being set.

The field here is left unchanged.

denis
-- -- -- -- -- -- --
vit esse estrany ?

spir.wikidot.com

November 19, 2010
On 11/19/10 1:20 PM, spir wrote:
> On Fri, 19 Nov 2010 09:18:47 -0800
> Andrei Alexandrescu<andrei at erdani.com>  wrote:
>
>> On 11/19/10 2:22 AM, spir wrote:
>>> Hum, is this really a transgression of const's promise? Each object's .name fields remains unchanged as expected. Rather only the symbolic relations (var-id<-->   object) change. It's another kind of change.
>>> Here, the 2 facts that the fields are called 'name' and that they hold values equal to var-ids, commonly called 'name' as well, just introduce confusion.
>>> What about this, is it also inacceptable?
>>>
>>> struct S
>>> {
>>>       const uint code;
>>> }
>>> auto a = S(1); // a<-->   obj1 (code:1)
>>> auto b = S(1); // b<-->   obj2 (code:2)
>>>
>>> swap(a, b);
>>> assert(a.code == 2); // a<-->   obj2 (code:2)
>>> assert(b.code == 1); // b<-->   obj1 (code:1)
>>
>> A const field is expected to always stay the same after being set.
>
> The field here is left unchanged.

If a constructor establishes the const field to have e.g. value 1, it would be quite surprising if that field actually becomes 2.

Andrei