http://d.puremagic.com/issues/show_bug.cgi?id=9498

           Summary: Rang violation using AA
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: timvol@ymail.com


--- Comment #0 from Tim Volckmann <timvol@ymail.com> 2013-02-12 11:26:48 PST ---
The following worked in DMD 2.060 (and previous versions):

string[string] myValues;

ref string getValue(string v) {
   return myValues[v];
}

void main() {
   getValue("myValue") = "myString";
}

But in 2.061 it throws a range violation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com
           Platform|x86_64                      |All
         OS/Version|Linux                       |All
           Severity|normal                      |regression


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498


Maxim Fomin <maxim@maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim@maxim-fomin.ru


--- Comment #1 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-02-12 11:49:32 PST ---
This is neither a bug nor a regression.

An element is accessed in return statement, which makes it an rvalue, so allocation if absence does not applies here.

It works as clarified in TDPL. From TDPL (p. 115):

"To read a value off an associative array given a key, just read aa [ key] . (The compiler distinguishes reads from writes and invokes slightly different functions.)" - it is implemented in druntime as aaGetValueX and aaGetRvalueX or something like that.

Further:

"If you try to read the value for a key not found in the associative array, a range violation exception is thrown."

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |INVALID


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |yebblies@gmail.com
         Resolution|INVALID                     |


--- Comment #2 from yebblies <yebblies@gmail.com> 2013-06-30 13:32:45 EST ---
Note the ref return from getValue, which makes 'myValues[v]' an lvalue.  It could still be invalid, but not for the reasons stated.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498



--- Comment #3 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-06-29 21:59:13 PDT ---
(In reply to comment #2)
> Note the ref return from getValue, which makes 'myValues[v]' an lvalue.  It could still be invalid, but not for the reasons stated.

This is irrelevant. The fact that function returns by ref indicates that value should not be copied but returned by ref. If "myValue" was present that would mean that pointer to the string is returned. Irrespective of how value is returned, myValues[v] is invalid value here.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498



--- Comment #4 from yebblies <yebblies@gmail.com> 2013-06-30 15:15:17 EST ---
(In reply to comment #3)
> (In reply to comment #2)
> > Note the ref return from getValue, which makes 'myValues[v]' an lvalue.  It could still be invalid, but not for the reasons stated.
> 
> This is irrelevant. The fact that function returns by ref indicates that value should not be copied but returned by ref. If "myValue" was present that would mean that pointer to the string is returned. Irrespective of how value is returned, myValues[v] is invalid value here.

This code works because indexing an AA with a key that does not exist is valid in an lvalue context:

int[string] aa;
aa["asd"] += 2;

The following code also indexes an AA with a missing key in an lvalue context:

int[string] aa;
ref int get() { return aa["asd"]; }
get() += 2;

The assumption here is that indexing an AA with a non-existing key in a context where an lvalue is expected does not result in a range violation.

Do you know of any reason why this is an incorrect assumption?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498



--- Comment #5 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-06-29 22:34:57 PDT ---
(In reply to comment #4)
> This code works because indexing an AA with a key that does not exist is valid in an lvalue context:
> 
> int[string] aa;
> aa["asd"] += 2;
> 
> The following code also indexes an AA with a missing key in an lvalue context:
> 
> int[string] aa;
> ref int get() { return aa["asd"]; }
> get() += 2;
> 
> The assumption here is that indexing an AA with a non-existing key in a context where an lvalue is expected does not result in a range violation.
> 
> Do you know of any reason why this is an incorrect assumption?

Actually D does not have notion of lvalue context - TDPL says about read and write operations. According to it, returning from function is a read operation.

And function refness does not guarantee that original lvalue will be modified. The use case could be:

int a = get();

which means refness is wiped out and operation is effectively a read operation. Situation could be follows:

ref int foo() { return aa["asd"]; }
int bar() { return aa["asd"]; }

not only this is confusing and inconsistent, but it defeats the purpose of having aaGetRvalueX - anyone who want allocation would be just putting ref to function declaration to make things works.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498



--- Comment #6 from yebblies <yebblies@gmail.com> 2013-06-30 15:59:48 EST ---
(In reply to comment #5)
> 
> Actually D does not have notion of lvalue context - TDPL says about read and write operations. According to it, returning from function is a read operation.
> 

TDPL does not completely define the language.  Unfortunately neither does the spec, it is defined through a combination of TDPL, the spec, and DMD.  When these disagree none are a definitive source.

The compiler most certainly has a notion of lvalue context for index expressions.

> And function refness does not guarantee that original lvalue will be modified. The use case could be:
> 
> int a = get();
> 
> which means refness is wiped out and operation is effectively a read operation. Situation could be follows:
> 
> ref int foo() { return aa["asd"]; }
> int bar() { return aa["asd"]; }
> 
> not only this is confusing and inconsistent, but it defeats the purpose of having aaGetRvalueX - anyone who want allocation would be just putting ref to function declaration to make things works.

I'm not sure how any of this is relevant.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9498



--- Comment #7 from Maxim Fomin <maxim@maxim-fomin.ru> 2013-06-29 23:43:51 PDT ---
(In reply to comment #6)
> > And function refness does not guarantee that original lvalue will be modified. The use case could be:
> > 
> > int a = get();
> > 
> > which means refness is wiped out and operation is effectively a read operation. Situation could be follows:
> > 
> > ref int foo() { return aa["asd"]; }
> > int bar() { return aa["asd"]; }
> > 
> > not only this is confusing and inconsistent, but it defeats the purpose of having aaGetRvalueX - anyone who want allocation would be just putting ref to function declaration to make things works.
> 
> I'm not sure how any of this is relevant.

Than you should read again if you don't see the relevance. Function returning AA value as discussed here is a case which should throw according to TDPL (spec is silent unfortunately) and current D implementation in case of non-ref functions. Presence of ref attribute does not matter because function performs read operation in the first place. How value is returned (by ref or not) is of secondary importance.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------