Thread overview
auto x = property: variable x cannot be declared to be a function
Nov 24, 2006
Lionello Lunesu
Nov 24, 2006
Stewart Gordon
Nov 24, 2006
Lionello Lunesu
Nov 25, 2006
Dave
November 24, 2006
When converting a (public) variable into a property (get/set) I suddenly got the compiler error mentioned in the subject.

The following code is a minimal test case:

#int prop() { return 0; }
#void main() {
#  auto x = prop;
#}

A workaround is to drop the "auto" and use the actual type: int x = prop;
or to to add an extra pair of (): auto x = prop();

I understand that "prop" is a function and therefor "auto" defers it as such and then fails to declare a variable of that type (which is why I'm posting it here, instead of in BugZilla.)

Would it break anything to treat this case such that a property behaves more like a variable, meaning that the type deferred would be the return type of the getter?

L.
November 24, 2006
Lionello Lunesu wrote:
> When converting a (public) variable into a property (get/set) I suddenly got the compiler error mentioned in the subject.
> 
> The following code is a minimal test case:
> 
> #int prop() { return 0; }
> #void main() {
> #  auto x = prop;
> #}
<snip>
> Would it break anything to treat this case such that a property behaves more like a variable, meaning that the type deferred would be the return type of the getter?

No.  AIUI property getting is what your code is supposed to do.

A function name by itself has no meaning without context.  There are four ways in which it can gain meaning from context:

(a) calling the function explicitly, using ()
(b) taking the function's address, using &
(c) setting the property, by putting it on the left-hand side of an =
(d) getting the property, by using it in an expression anywhere where a value is required.

The problem appears to be that, in this context, the compiler fails to detect the context before trying to process the declaration.  Really, using it as an initializer, whether in an auto declaration or one of specified type, should be an instance of (d).

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
November 24, 2006
"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:ek7j2c$1rk9$1@digitaldaemon.com...
> Lionello Lunesu wrote:
>> When converting a (public) variable into a property (get/set) I suddenly got the compiler error mentioned in the subject.
>>
>> The following code is a minimal test case:
>>
>> #int prop() { return 0; }
>> #void main() {
>> #  auto x = prop;
>> #}
> <snip>
>> Would it break anything to treat this case such that a property behaves more like a variable, meaning that the type deferred would be the return type of the getter?
>
> No.  AIUI property getting is what your code is supposed to do.

Yes, that's what I meant :S

L.


November 25, 2006
Stewart Gordon wrote:
> Lionello Lunesu wrote:
>> When converting a (public) variable into a property (get/set) I suddenly got the compiler error mentioned in the subject.
>>
>> The following code is a minimal test case:
>>
>> #int prop() { return 0; }
>> #void main() {
>> #  auto x = prop;
>> #}
> <snip>
>> Would it break anything to treat this case such that a property behaves more like a variable, meaning that the type deferred would be the return type of the getter?
> 
> No.  AIUI property getting is what your code is supposed to do.
> 
> A function name by itself has no meaning without context.  There are four ways in which it can gain meaning from context:
> 
> (a) calling the function explicitly, using ()
> (b) taking the function's address, using &
> (c) setting the property, by putting it on the left-hand side of an =
> (d) getting the property, by using it in an expression anywhere where a value is required.
> 
> The problem appears to be that, in this context, the compiler fails to detect the context before trying to process the declaration.  Really, using it as an initializer, whether in an auto declaration or one of specified type, should be an instance of (d).
> 

I think you're right - this is a bug. Besides which, it's inconsistent since the requirement to use () to call any [non function literal] function with an empty parameter list was dropped months ago.

Has this been added to bugzilla?

Thanks,

- Dave

> Stewart.
>