www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - auto x = property: variable x cannot be declared to be a function

reply Lionello Lunesu <lio lunesu.remove.com> writes:
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.
Nov 24 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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;
 #}

 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.
Nov 24 2006
next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"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;
 #}

 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.
Nov 24 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
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;
 #}

 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.
 

Nov 24 2006