While we're lynching features, how bout' them omittable parens?

"Jérôme M. Berger" jeberger at free.fr
Tue May 19 14:49:19 PDT 2009


Robert Fraser wrote:
> Chad J wrote:
>> Nevermind properties.  Any chance we can forbid the omittable
>> parentheses, at least in the lhs of an assignment expression?
>>
>> In the more general case, any value type that gets modified but never
>> read or copied elsewhere is probably either dead code, a bug, or a
>> benchmark.  The latter is easy to fix by adding the necessary read/copy
>> (return the value, pass it to a global or function, etc).  It'd be great
>> if this kind of thing were a compile time error.
>>
>> Code like this shouldn't compile:
>>
>> struct S { int a = 0; }
>> S foo() { S s; return s; }
>>
>> void main()
>> {
>>     foo.a++;
>> }
> 
> Whatever solution to this is chosen *please* don't make "get", "set", 
> "value" or "prop" into keywords! "in", "out", "body" and "shared" used 
> to be common features of my coding style; I'm not sure it can take 
> another blow. As Andrei mentioned somewhere, keywords aren't cheap.

	How about:

int x { setter, getter };
int setter();
void getter (int);

	Where either one of the accessors may be null (or omitted):

int readonly { null, getter };
int writeonly { setter, null };

  - It doesn't need a new keyword;
  - It can't be confused with function declarations because those 
need parentheses anyway;
  - Ideally, the compiler would infer the type of the accessor from 
its prototype (i.e if it doesn't take any arguments and returns T, 
then it's the getter, if it takes a T and returns void then it's the 
setter, otherwise it's an error).

	Of course, this would *not* allocate any space in the class/struct.

		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20090519/e891c054/attachment.pgp>


More information about the Digitalmars-d mailing list