Properties: a.b.c = 3

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Jul 30 09:56:47 PDT 2009


Steven Schveighoffer wrote:
> On Wed, 29 Jul 2009 15:14:04 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Wed, 29 Jul 2009 14:08:18 -0400, Andrei Alexandrescu 
>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>
>>>> Steven Schveighoffer wrote:
>>>>> It would be nice if the compiler could help by simply rejecting 
>>>>> what it can reject (assignment to rvalues), but other than that, 
>>>>> there's not much that can be done.
>>>>>  This can be detected in simple cases, but in the case where the 
>>>>> end point is a function, it will be difficult or impossible.
>>>>
>>>> I think it is eminently possible, but we must figure a solution that 
>>>> doesn't complicate the language all too much.
>>>  Here is a struct, defined in a .di file:
>>>  struct S
>>> {
>>>   private int _c;
>>>   int c();
>>>   void c(int n);
>>> }
>>>  struct S2
>>> {
>>>   S b();
>>> }
>>>  Now, in your main file you have:
>>>  void main()
>>> {
>>>   S2 a;
>>>   a.b.c = 3;
>>> }
>>>  How in the world is the compiler supposed to know whether to allow 
>>> this or not?
>>
>> By making a conservative decision.
> 
> If we have restrictive shit like this where the compiler thinks it knows 
> better than me, can we at least only have it in SafeD?

It's a matter of degree. There's already plenty of correct code that D 
or other languages deem as invalid. So the issue is how conservative the 
conservative decision would be.

Andrei



More information about the Digitalmars-d mailing list