Error: xxx is not an lvalue

Tyro[a.c.edwards] nospam at
Sun May 3 05:16:06 PDT 2009

On 5/3/2009 8:17 PM, Unknown W. Brackets wrote:
> Well, if you really want a "protected" associative array, or array for
> that matter, you probably should define a wrapper class that inlines the
> access you're willing to allow.
>  From a basic perspective, _testMap is a structure of data. Although it
> is private, there's no reason it can't be modified through an accessor.
> Without a setter, the only thing that should fail is test.testMap =
> something. Requiring a setter for any minor change makes no sense.

I was following until now... If I can modify said private member at a
whim, why on earth would I prevent this case? Is this because I would
be assigning it a completely new value vice simply modifying its
content? If that is the case, am I correct in saying that this
characteristic is applicable only to arrays?

> Compare it to this: if you have a class that has a member object (e.g. a
> User with a Socket member variable), should it be necessary to have a
> setter to change the Socket? Can't the Socket handle its own
> private/public-ness?
> Arrays and associative arrays are the same, except that the members you
> use are public.
> -[Unknown]

Got you... I think I understand. That being the case though, wouldn't
it be just as useful to build the same "accessor" capability into
opAssign such that you can:

	class Foo
	    private sometype _data;
	    public ref typeof(_data) opAssign() { return _data; }

	Foo b = new foo;
	b[0] = 1;

Why is it necessary to have a separate/different "accessor" function?

> Tyro[a.c.edwards] wrote:
>> On 5/3/2009 6:25 PM, Unknown W. Brackets wrote:
>>> This code works fine (D 2.x only):
>>> class Test
>>> {
>>> private int[int] _testMap;
>>> public ref int[int] testMap() {return _testMap;}
>>> }
>>> void main()
>>> {
>>> Test test = new Test();
>>> test.testMap[0] = 1;
>>> }
>>> Note the "ref". Otherwise, a value is returned which is not modifiable.
>>> This will also fix test.array.length. Nothing wrong here, no creepy bad
>>> temporary property problems.
>> Is this an intended or even desirable "feature" of the language or
>> just something that happens to work in D 2.x? I ask because to the
>> untrained eye, it is unclear exactly what is happening. There is
>> nothing to inform me that _testMap can be modified from outside the
>> class. Even with "ref" there it doesn't make it any clearer.
>> Matter of fact, I just had a problem in Phobos 2 where a function was
>> defined like that and I had to comment out the "ref" for it to work.
>> Kept telling me that some array was not an lvalue. The minute I
>> commented out the "ref", everything worked like a charm.
>> Also it makes more sense to me to have separate functions as getters
>> and setters. Maybe that's only because I lacking proper training in
>> the art of computer programming though.
>>> I suppose you could also try returning a pointer to an associative array
>>> (e.g. with &) in D 1.x.
>>> -[Unknown]
>>> flourish wrote:
>>>> Hi,
>>>> why does the following code not compile -- or how to declare a (usable)
>>>> property of an associative array field?
>>>> //////////////////////
>>>> class Test
>>>> {
>>>> private int[int] _testMap;
>>>> public int[int] testMap() {return _testMap;}
>>>> }
>>>> void main()
>>>> {
>>>> Test test = new Test();
>>>> test.testMap[0] = 1;
>>>> }
>>>> /////////////////
>>>> *** Error: test.testMap() is not an lvalue
>>>> Regards,
>>>> flourish

More information about the Digitalmars-d mailing list