www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: const/immutable member functions

reply bearophile <bearophileHUGS lycos.com> writes:
There are six, seven or more people that wish to do something about this
situation. TDPL is the D2 reference, but few little changes over its first
edition are acceptable if they improve the D language a little.

- Trass3r: asks if the code is ambiguous
- Jonathan M Davis: does't like it and puts const/etc on the right
- Simen kjaeraas thinks it's ambiguous though, and should be disallowed, or at
very least, discouraged.
- Jens Mueller: Preferred style is to write const on the right
- Andrej Mitrovic suggests to use   but says it clutters up source code.
- I agree with Jonathan M Davis.

What other people think about this situation? Do you want const/immutable to be
required on the right, or do you prefer the current situation, or do you prefer
some other solution?

This is the bug report, that Walter has closed, but if necessary it may be
opened up again if enough people are interested in the topic:
http://d.puremagic.com/issues/show_bug.cgi?id=4070

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=4040

Bye,
bearophile
Jan 24 2011
next sibling parent Torarin <torarind gmail.com> writes:
2011/1/24 bearophile <bearophileHUGS lycos.com>:
 What other people think about this situation? Do you want const/immutable to
be required on the right, or do you prefer the current situation, or do you
prefer some other solution?

If const is required to go on the right, what do you do if you want to mark a bunch of functions const inside {}? Torarin
Jan 24 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 24 Jan 2011 13:36:36 -0500, bearophile <bearophileHUGS lycos.com>  
wrote:

 There are six, seven or more people that wish to do something about this  
 situation. TDPL is the D2 reference, but few little changes over its  
 first edition are acceptable if they improve the D language a little.

 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the right
 - Simen kjaeraas thinks it's ambiguous though, and should be disallowed,  
 or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up source code.
 - I agree with Jonathan M Davis.

 What other people think about this situation? Do you want  
 const/immutable to be required on the right, or do you prefer the  
 current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined. I think we have more important problems to worry about than this. -Steve
Jan 24 2011
next sibling parent so <so so.do> writes:
 I think we have more important problems to worry about than this.

IMHO fixing trivial issues first or as soon as possible is better. Not saying this is one of them, i mean generally.
Jan 24 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 I wouldn't say that I *prefer* the current solution, but the current  
 solution is not so bad that I need it changed.

 It works fine, despite being confusing.  If it wasn't consistent with  
 the rest of the attributes, I'd say it was in need of changes, but it  
 fits within the scheme already outlined.

 I think we have more important problems to worry about than this.

 -Steve

I'm not sure either but I usually use the suffix version. The question is if there is any case where the prefix one could be harmful (i.e. not resulting in an error message). Maybe the following?: class Foo { private static Bar[] bar; // author thinks it returns a const pointer etc. const Foo* ptr() { return bar.ptr; } }
Jan 24 2011
prev sibling next sibling parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Mon, 24 Jan 2011 13:36:36 -0500, bearophile 
 <bearophileHUGS lycos.com> wrote:
 
 There are six, seven or more people that wish to do something about 
 this situation. TDPL is the D2 reference, but few little changes over 
 its first edition are acceptable if they improve the D language a little.

 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the right
 - Simen kjaeraas thinks it's ambiguous though, and should be 
 disallowed, or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up source code.
 - I agree with Jonathan M Davis.

 What other people think about this situation? Do you want 
 const/immutable to be required on the right, or do you prefer the 
 current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined.

It's a problem for all of the other attributes as well. I wish it were disallowed for all of them. Incidentally, putting it afterwards always works. Putting it before doesn't always work, due to compiler bugs (for example, prefix 'pure' doesn't work for inner functions).
Jan 24 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 24 January 2011 12:08:29 Don wrote:
 Steven Schveighoffer wrote:
 On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
 
 <bearophileHUGS lycos.com> wrote:
 There are six, seven or more people that wish to do something about
 this situation. TDPL is the D2 reference, but few little changes over
 its first edition are acceptable if they improve the D language a
 little.
 
 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the right
 - Simen kjaeraas thinks it's ambiguous though, and should be
 disallowed, or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up source code.
 - I agree with Jonathan M Davis.
 
 What other people think about this situation? Do you want
 const/immutable to be required on the right, or do you prefer the
 current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined.

It's a problem for all of the other attributes as well. I wish it were disallowed for all of them. Incidentally, putting it afterwards always works. Putting it before doesn't always work, due to compiler bugs (for example, prefix 'pure' doesn't work for inner functions).

There there is a bug that attributes on constructors don't show up in generated .di files if they're on the right. I think that the real problem with putting them all on the right is that attributes such as static, public, and private are on the left in other languages, so it would be really weird to require that they be on the right. Still, it might be worth it. - Jonathan M Davis
Jan 24 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 I think we have more important problems to worry about than this.

I agree. On the other hand in other languages I've seen that many small troubles pile up and reduce the enjoyment of using a language. Bye, bearophile
Jan 24 2011
prev sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Monday 24 January 2011 12:08:29 Don wrote:
 Steven Schveighoffer wrote:
 On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
 
 <bearophileHUGS lycos.com> wrote:
 There are six, seven or more people that wish to do something about
 this situation. TDPL is the D2 reference, but few little changes over
 its first edition are acceptable if they improve the D language a
 little.
 
 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the right
 - Simen kjaeraas thinks it's ambiguous though, and should be
 disallowed, or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up source code.
 - I agree with Jonathan M Davis.
 
 What other people think about this situation? Do you want
 const/immutable to be required on the right, or do you prefer the
 current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined.

It's a problem for all of the other attributes as well. I wish it were disallowed for all of them. Incidentally, putting it afterwards always works. Putting it before doesn't always work, due to compiler bugs (for example, prefix 'pure' doesn't work for inner functions).

There there is a bug that attributes on constructors don't show up in generated .di files if they're on the right. I think that the real problem with putting them all on the right is that attributes such as static, public, and private are on the left in other languages, so it would be really weird to require that they be on the right. Still, it might be worth it.

Can't one have only the type qualifiers on the right? I mean it's only confusing for those. pure/nothrow int foo(); causes no confusion at all. The access qualifiers also work fine in the beginning. On the right they won't even compile. Jens
Jan 24 2011
prev sibling next sibling parent so <so so.do> writes:
On Mon, 24 Jan 2011 20:41:17 +0200, Torarin <torarind gmail.com> wrote:

 2011/1/24 bearophile <bearophileHUGS lycos.com>:
 What other people think about this situation? Do you want  
 const/immutable to be required on the right, or do you prefer the  
 current situation, or do you prefer some other solution?

If const is required to go on the right, what do you do if you want to mark a bunch of functions const inside {}? Torarin

I love that one, it is also quite explicit, we should definitely keep it. But i agree with all that the other case should be disallowed.
Jan 24 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Torarin <torarind gmail.com> wrote:

 2011/1/24 bearophile <bearophileHUGS lycos.com>:
 What other people think about this situation? Do you want  
 const/immutable to be required on the right, or do you prefer the  
 current situation, or do you prefer some other solution?

If const is required to go on the right, what do you do if you want to mark a bunch of functions const inside {}?

The suggestion is only for const alone on the left-hand side. const: and const{} would not be affected by such a change. That said, I consider const Foo bar(); to be a bug, and mercilessly squish it. I always put const on the right side of functions, and should I ever write coding guidelines for D, putting it on the left would be a capital offense. -- Simen
Jan 24 2011
prev sibling next sibling parent Torarin <torarind gmail.com> writes:
2011/1/24 Simen kjaeraas <simen.kjaras gmail.com>:
 The suggestion is only for const alone on the left-hand side. const: and
 const{} would not be affected by such a change.

You're right, it's not confusing at all. It makes perfect sense for function attributes to go on the right. But then I'd like all of them to go there, like Jonathan suggested. Torarin
Jan 24 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/24/2011 07:36 PM, bearophile wrote:
 What other people think about this situation? Do you want const/immutable to
be required on the right, or do you prefer the current situation, or do you
prefer some other solution?

Comparing with C-like typing syntax that, I guess, are planned for deprecation: C typing is not wrong, ambiguous, just arguably more difficult to decode, and unnecessary because we have a better alternative. IIUC, prefixed const and the like instead are not only unnecessary, but inherently ambiguous. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 24 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 24 January 2011 13:52:49 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Monday 24 January 2011 12:08:29 Don wrote:
 Steven Schveighoffer wrote:
 On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
 
 <bearophileHUGS lycos.com> wrote:
 There are six, seven or more people that wish to do something about
 this situation. TDPL is the D2 reference, but few little changes
 over its first edition are acceptable if they improve the D
 language a little.
 
 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the right
 - Simen kjaeraas thinks it's ambiguous though, and should be
 disallowed, or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up source
 code. - I agree with Jonathan M Davis.
 
 What other people think about this situation? Do you want
 const/immutable to be required on the right, or do you prefer the
 current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined.

It's a problem for all of the other attributes as well. I wish it were disallowed for all of them. Incidentally, putting it afterwards always works. Putting it before doesn't always work, due to compiler bugs (for example, prefix 'pure' doesn't work for inner functions).

There there is a bug that attributes on constructors don't show up in generated .di files if they're on the right. I think that the real problem with putting them all on the right is that attributes such as static, public, and private are on the left in other languages, so it would be really weird to require that they be on the right. Still, it might be worth it.

Can't one have only the type qualifiers on the right? I mean it's only confusing for those. pure/nothrow int foo(); causes no confusion at all. The access qualifiers also work fine in the beginning. On the right they won't even compile.

I'm surprised that they don't work on the right. The argument for allowing const on the left-hand side has always been consistency - that all function attributes work the same. If that's not the case, then it seems to me like a definite argument for disallowing const on the left. - Jonathan m Davis
Jan 24 2011
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Monday 24 January 2011 13:52:49 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Monday 24 January 2011 12:08:29 Don wrote:
 Steven Schveighoffer wrote:
 On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
 
 <bearophileHUGS lycos.com> wrote:
 There are six, seven or more people that wish to do something about
 this situation. TDPL is the D2 reference, but few little changes
 over its first edition are acceptable if they improve the D
 language a little.
 
 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the right
 - Simen kjaeraas thinks it's ambiguous though, and should be
 disallowed, or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up source
 code. - I agree with Jonathan M Davis.
 
 What other people think about this situation? Do you want
 const/immutable to be required on the right, or do you prefer the
 current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined.

It's a problem for all of the other attributes as well. I wish it were disallowed for all of them. Incidentally, putting it afterwards always works. Putting it before doesn't always work, due to compiler bugs (for example, prefix 'pure' doesn't work for inner functions).

There there is a bug that attributes on constructors don't show up in generated .di files if they're on the right. I think that the real problem with putting them all on the right is that attributes such as static, public, and private are on the left in other languages, so it would be really weird to require that they be on the right. Still, it might be worth it.

Can't one have only the type qualifiers on the right? I mean it's only confusing for those. pure/nothrow int foo(); causes no confusion at all. The access qualifiers also work fine in the beginning. On the right they won't even compile.

I'm surprised that they don't work on the right. The argument for allowing const on the left-hand side has always been consistency - that all function attributes work the same. If that's not the case, then it seems to me like a definite argument for disallowing const on the left.

I do not know what are you referring to when you say function attributes. I distinguish the following: type qualifiers: const, immutable, maybe also inout function attributes: pure, nothrow storage class: ref, in, out, static access qualifiers: private, package, protected, public, export Storage class and access qualifies should go left only in my opinion and that's how dmd behaves. Function attributes can go left and right and I think there is nothing wrong with allowing that because there is no confusion. Even though I like them to be right as well. But this is matter of style. There is only confusion for type qualifies. Namely does the qualifier apply to the return type or the function (better said the type of this). Now it is consistent in the sense that const: int foo(); const { int foo(); } const int foo(); all mean the same. And Walter seems to be unsure whether forbidding const void foo() is worth the trouble, isn't it? I see and felt the pain for newcomers to decipher the meaning of const void foo(); I see two options: Either we clarify the documentation (e.g. examples) to help newcomers or we fix it in the front end. Picking the second option means to provide a patch and send it to review. Picking the first option means improving http://www.digitalmars.com/d/2.0/const3.html Jens
Jan 25 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jens Mueller:

 all mean the same. And Walter seems to be unsure whether forbidding
 const void foo() is worth the trouble, isn't it?
 I see and felt the pain for newcomers to decipher the meaning of
 const void foo();
 I see two options:

Now I'd like to know what Andrei thinks about this. Bye, bearophile
Jan 25 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 25 January 2011 01:45:49 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Monday 24 January 2011 13:52:49 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Monday 24 January 2011 12:08:29 Don wrote:
 Steven Schveighoffer wrote:
 On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
 
 <bearophileHUGS lycos.com> wrote:
 There are six, seven or more people that wish to do something
 about this situation. TDPL is the D2 reference, but few little
 changes over its first edition are acceptable if they improve
 the D language a little.
 
 - Trass3r: asks if the code is ambiguous
 - Jonathan M Davis: does't like it and puts const/etc on the
 right - Simen kjaeraas thinks it's ambiguous though, and should
 be disallowed, or at very least, discouraged.
 - Jens Mueller: Preferred style is to write const on the right
 - Andrej Mitrovic suggests to use   but says it clutters up
 source code. - I agree with Jonathan M Davis.
 
 What other people think about this situation? Do you want
 const/immutable to be required on the right, or do you prefer
 the current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined.

It's a problem for all of the other attributes as well. I wish it were disallowed for all of them. Incidentally, putting it afterwards always works. Putting it before doesn't always work, due to compiler bugs (for example, prefix 'pure' doesn't work for inner functions).

There there is a bug that attributes on constructors don't show up in generated .di files if they're on the right. I think that the real problem with putting them all on the right is that attributes such as static, public, and private are on the left in other languages, so it would be really weird to require that they be on the right. Still, it might be worth it.

Can't one have only the type qualifiers on the right? I mean it's only confusing for those. pure/nothrow int foo(); causes no confusion at all. The access qualifiers also work fine in the beginning. On the right they won't even compile.

I'm surprised that they don't work on the right. The argument for allowing const on the left-hand side has always been consistency - that all function attributes work the same. If that's not the case, then it seems to me like a definite argument for disallowing const on the left.

I do not know what are you referring to when you say function attributes. I distinguish the following: type qualifiers: const, immutable, maybe also inout function attributes: pure, nothrow storage class: ref, in, out, static access qualifiers: private, package, protected, public, export Storage class and access qualifies should go left only in my opinion and that's how dmd behaves. Function attributes can go left and right and I think there is nothing wrong with allowing that because there is no confusion. Even though I like them to be right as well. But this is matter of style. There is only confusion for type qualifies. Namely does the qualifier apply to the return type or the function (better said the type of this). Now it is consistent in the sense that const: int foo(); const { int foo(); } const int foo(); all mean the same. And Walter seems to be unsure whether forbidding const void foo() is worth the trouble, isn't it? I see and felt the pain for newcomers to decipher the meaning of const void foo(); I see two options: Either we clarify the documentation (e.g. examples) to help newcomers or we fix it in the front end. Picking the second option means to provide a patch and send it to review. Picking the first option means improving http://www.digitalmars.com/d/2.0/const3.html

Anything that modifies a function could be considered a function attribute: public, static, nothrow, pure, property, const, etc. Something that modifies the return value of a function or a function parameter isn't a function attribute. In the past, Walter's argument for const working as it is is that it is consistent with the other function attributes and that requiring that it be on the right would be inconsistent. - Jonathan M Davis
Jan 25 2011
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Tuesday 25 January 2011 01:45:49 Jens Mueller wrote:
 
 I do not know what are you referring to when you say function attributes.
 I distinguish the following:
 type qualifiers: const, immutable, maybe also inout
 function attributes: pure, nothrow
 storage class: ref, in, out, static
 access qualifiers: private, package, protected, public, export
 
 Storage class and access qualifies should go left only in my opinion and
 that's how dmd behaves.
 Function attributes can go left and right and I think there is nothing
 wrong with allowing that because there is no confusion. Even though I
 like them to be right as well. But this is matter of style.
 There is only confusion for type qualifies. Namely does the qualifier
 apply to the return type or the function (better said the type of this).
 Now it is consistent in the sense that
 const:
     int foo();
 const {
     int foo();
 }
 const int foo();
 
 all mean the same. And Walter seems to be unsure whether forbidding
 const void foo() is worth the trouble, isn't it?
 I see and felt the pain for newcomers to decipher the meaning of
 const void foo();
 I see two options:
 Either we clarify the documentation (e.g. examples) to help newcomers or
 we fix it in the front end. Picking the second option means to provide a
 patch and send it to review. Picking the first option means improving
 http://www.digitalmars.com/d/2.0/const3.html

Anything that modifies a function could be considered a function attribute: public, static, nothrow, pure, property, const, etc. Something that modifies the return value of a function or a function parameter isn't a function attribute.

You want to make a distinction regarding the modification. Those ones are called function attributes because they change a function in that regard. I'm not sure whether this clarifies things. I just think const/immutable as type qualifiers and you can apply those to member functions because the type of this object can be qualified as const/immutable.
 In the past, Walter's argument for const working as it is is that it is 
 consistent with the other function attributes and that requiring that it be on 
 the right would be inconsistent.

I didn't have that impression reading the mentioned bug reports. It seems there is more that I'm missing. Jens
Jan 25 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Jens Mueller:

 I didn't have that impression reading the mentioned bug reports. It
 seems there is more that I'm missing.

See Walter answers here: http://d.puremagic.com/issues/show_bug.cgi?id=4070 Bye, bearophile
Jan 25 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
bearophile wrote:
 Jens Mueller:
 
 I didn't have that impression reading the mentioned bug reports. It
 seems there is more that I'm missing.

See Walter answers here: http://d.puremagic.com/issues/show_bug.cgi?id=4070

I'm not getting it. In comment 1 Walter refers to const:, const {} and const (let's say inline) and they are all consistent (all are written left). That's his point. And forcing now const for the last syntax to be on the right makes it inconsistent. So he weighs consistency against the possible confusion and favors consistency in the end. That is a valid point. I do not see Walter arguing for consistency with non-type qualifiers. Meaning Walter's argument is valid but most of us weigh things here differently. Most favor inconsistency over possible confusion in this case. That's why the problem is currently solved as a matter of good style. I'd love to see that change but I think it's unfair to force it on Walter. Because he is not convinced yet. Next step is either propose a patch (i.e. trying harder to convince Walter, hoping that a patch may change things for him.) or document a preferred style in this regard clarifying the confusion. Jens
Jan 25 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/25/2011 10:45 AM, Jens Mueller wrote:
 I distinguish the following:
 type qualifiers: const, immutable, maybe also inout
 function attributes: pure, nothrow
 storage class: ref, in, out, static
 access qualifiers: private, package, protected, public, export

Nice & clear classification. Then, if you allow replacing "attribute" and "class" by "qualifier" (which by the way both are somewhat confusing because of other common meanings), you get a super-class of qualifiers. All are put aside a name which can denote a plain var, a type etc... Only in case of function they can be prefixed to the whole signature, which creates ambiguity with the return type: const int square (int x) {...} // func or return type? The obvious consistent choice, imo, would be to place them aside the function name: int const square (int x) {...} const int square (int x) {...} const int const square (int x) {...} but indeed would be a syntactic revolution ;-) Another solution would be to enforce parentheses except in the case of function: const int square (int x) {...} // func const(int) square (int x) {...} // return type Denis -- _________________ vita es estrany spir.wikidot.com
Jan 25 2011