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