www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - AA default value?

reply "Janice Caron" <caron800 googlemail.com> writes:
The big problem for me with associative arrays is that I often have to
write ugly code like:

    auto p = key in aa;
    if (p)
    {
    	auto val = *p;
    }
    else
    {
        /* whatever */
    }

instead of merely

    auto val = aa[key];

In order to avoid superfluous lookups, the code that I actually end up
writing doesn't use the square brackets at all, which kind of defeats
the object of the built-in array-like syntax. What would seriously
make for nicely readable code would be if the behavior of aa[key]
could be changed. Currently, aa[key] throws an exception (in Debug
mode) or falls over (in Release mode) if key does not exist. Wouldn't
it be nicer if, instead, it simply returned

	typeof(aa[key]).init

if the key was not present in the array? Or perhaps an even more
exotic syntax like

    auto val = aa[key; defaultValue];

might work.

(None of this would preclude people from using "in" if they explicitly
wanted to check).
Jan 25 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.24.1201263099.5260.digitalmars-d puremagic.com...


 Wouldn't
 it be nicer if, instead, it simply returned

 typeof(aa[key]).init

 if the key was not present in the array?


What's funny is that a while ago ((long) before 1.0), if you looked up a key 
in an AA and the key didn't exist, it'd be added with a value of 
typeof(aa[key]).init.  So

int[int] aa;
writefln(aa[5]);

would give "0" as the output.

This was to mirror the behavior of C++'s std::map but many people opposed 
it, so now we have what we have now..

The issue is that you can't cover all the bases with a single type.  Some 
people want the auto-insertion, some don't.  Some want it to disallow 
updates, i.e. allow a key-value pair to be inserted but never modified. 
Some want the opposite, where you have to explicitly use an insert method to 
insert the values, but once they're in, they can be modified as much as you 
like.

At least the nice thing about the AAs is that they're simple to build custom 
containers on top of them, so most/all of these things can be implemented as 
structs wrapping them.  The downside is that with the current set of 
operator overloads and features, you can never make a custom type that can 
replace the builtin one in all cases.
Jan 25 2008
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Jarrett Billingsley wrote:

 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.24.1201263099.5260.digitalmars-d puremagic.com...
 

 Wouldn't
 it be nicer if, instead, it simply returned

 typeof(aa[key]).init

 if the key was not present in the array?


 
 What's funny is that a while ago ((long) before 1.0), if you looked up a key 
 in an AA and the key didn't exist, it'd be added with a value of 
 typeof(aa[key]).init.  So
 
 int[int] aa;
 writefln(aa[5]);
 
 would give "0" as the output.
 
 This was to mirror the behavior of C++'s std::map but many people opposed 
 it, so now we have what we have now..


I believe the implemented solution to the old problem overshoot the best 
solution, which would have been to make a rvalue expression aa[5] return 
0, but *without* inserting 5 into the aa.

I have for ages had the following two simple utility functions in most 
code I write that uses AAs:

T get(T,U)(T[U] aa, U key) {
         T* ptr = key in aa;
         if (ptr)
                 return *ptr;
         return T.init;
}

T get(T,U,int dummy=1)(T[U] aa, U key, lazy T defaultValue) {
         T* ptr = key in aa;
         if (ptr)
         	return *ptr;
        	return defaultValue;
}

and almost always use aa.get(5), instead of aa[5].


 The issue is that you can't cover all the bases with a single type.  Some 
 people want the auto-insertion, some don't.  Some want it to disallow 
 updates, i.e. allow a key-value pair to be inserted but never modified. 
 Some want the opposite, where you have to explicitly use an insert method to 
 insert the values, but once they're in, they can be modified as much as you 
 like.
 
 At least the nice thing about the AAs is that they're simple to build custom 
 containers on top of them, so most/all of these things can be implemented as 
 structs wrapping them.  The downside is that with the current set of 
 operator overloads and features, you can never make a custom type that can 
 replace the builtin one in all cases. 


The biggest problem with custom containers is the lack of a reference 
return type.

-- 
Oskar
Jan 25 2008
parent reply Sean Kelly <sean f4.ca> writes:
Oskar Linde wrote:

 Jarrett Billingsley wrote:

 "Janice Caron" <caron800 googlemail.com> wrote in message
 news:mailman.24.1201263099.5260.digitalmars-d puremagic.com...


 Wouldn't
 it be nicer if, instead, it simply returned

 typeof(aa[key]).init

 if the key was not present in the array?


 What's funny is that a while ago ((long) before 1.0), if you looked up
 a key in an AA and the key didn't exist, it'd be added with a value of
 typeof(aa[key]).init.  So

 int[int] aa;
 writefln(aa[5]);

 would give "0" as the output.

 This was to mirror the behavior of C++'s std::map but many people
 opposed it, so now we have what we have now..


 
 I believe the implemented solution to the old problem overshoot the best
 solution, which would have been to make a rvalue expression aa[5] return
 0, but *without* inserting 5 into the aa.


Agreed.  And I think this was brought up at the time, but it wasn't
implemented for some reason.


Sean
Jan 25 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Sean Kelly Wrote:


 Oskar Linde wrote:

 I believe the implemented solution to the old problem overshoot the best
 solution, which would have been to make a rvalue expression aa[5] return
 0, but *without* inserting 5 into the aa.


 
 Agreed.  And I think this was brought up at the time, but it wasn't
 implemented for some reason.


That solution is assuming a specific answer to the question of "should indexing
a non-existent entry be an error?".  Sometimes, I write code that assumes stuff
will be pre-existing in an AA / STL map.  When this is the case, I prefer the D
behavior.  When code works better with defaults, it's annoying.  I'd really
prefer to have a choice.

Additionally, AA's of classes that return null for unused indexes isn't
particularly helpful.  Returning a non-duped default object is usually worse
than returning null.  To me, there seems to be enough variation in what people
would want that some kind of policy (template paramter, included function
object, etc...) would be better.
Jan 25 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 1/25/08, Jason House <jason.james.house gmail.com> wrote:

 I'd really prefer to have a choice.


Yeah! I'll second that.

Not sure how it would work though. Maybe something like:

    int[int] aa;
    auto x = aa[5]; // run-time error

    aa.default = 0;
    auto y = aa[5]; // y = 0;


 Additionally, AA's of classes that return null for unused indexes isn't
particularly helpful.  Returning a non-duped default object is usually worse
than returning null.  To me, there seems to be enough variation in what people
would want that some kind of policy (template paramter, included function
object, etc...) would be better.


Sounds good to me. Maybe the .default property could be lazy (so it
could call new when needed)?
Jan 25 2008
parent Jason House <jason.james.house gmail.com> writes:
Janice Caron Wrote:


 On 1/25/08, Jason House <jason.james.house gmail.com> wrote:

 I'd really prefer to have a choice.


 
 Yeah! I'll second that.
 
 Not sure how it would work though. Maybe something like:
 
     int[int] aa;
     auto x = aa[5]; // run-time error
 
     aa.default = 0;
     auto y = aa[5]; // y = 0;
 

 Additionally, AA's of classes that return null for unused indexes isn't
particularly helpful.  Returning a non-duped default object is usually worse
than returning null.  To me, there seems to be enough variation in what people
would want that some kind of policy (template paramter, included function
object, etc...) would be better.


 
 Sounds good to me. Maybe the .default property could be lazy (so it
 could call new when needed)?


I'd be content with (lazy) syntax above.  Two gotchas:
* The default keyword (used in switches) may block that property
* New AA's are null and property access would fail.  Of course, I'd like to see
that changed anyway.
Jan 25 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Janice Caron wrote:

 Wouldn't
 it be nicer if, instead, it simply returned
 
 	typeof(aa[key]).init
 
 if the key was not present in the array?


But then you can't tell wheter the key was present and the value was 
init, or it was not present at all.
Jan 25 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 1/25/08, Ary Borenszweig <ary esperanto.org.ar> wrote:

 Janice Caron wrote:

 Wouldn't
 it be nicer if, instead, it simply returned

       typeof(aa[key]).init

 if the key was not present in the array?


 But then you can't tell wheter the key was present and the value was
 init, or it was not present at all.


If knowing that is important, you must use "in", as you always have
done. I wasn't for one moment suggesting deprecating "in". However,
there are plenty of circumstances where the distinction is
unimportant.

Another approach would be to specify the default at the time you make
the call (instead of relying on init). Of course, for that you'd need
a new syntax - e.g.

    aa[key; defaultValue]
or
    aa[key ? defaultValue]
or
    aa[key else defaultValue]
etc.

But yeah - under the first idea, if you really need to tell whether
the key was present and the value was init, you'd just do

    key in init

i.e. no change. Existing code still does the job.
Jan 25 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
Janice Caron, el 25 de enero a las 14:58 me escribiste:

 On 1/25/08, Ary Borenszweig <ary esperanto.org.ar> wrote:

 Janice Caron wrote:

 Wouldn't
 it be nicer if, instead, it simply returned

       typeof(aa[key]).init

 if the key was not present in the array?


 But then you can't tell wheter the key was present and the value was
 init, or it was not present at all.


 
 If knowing that is important, you must use "in", as you always have
 done. I wasn't for one moment suggesting deprecating "in". However,
 there are plenty of circumstances where the distinction is
 unimportant.
 
 Another approach would be to specify the default at the time you make
 the call (instead of relying on init). Of course, for that you'd need
 a new syntax - e.g.
 
     aa[key; defaultValue]
 or
     aa[key ? defaultValue]
 or
     aa[key else defaultValue]
 etc.


aa.get(key, defaultvalue) (a la python)?

I think your proposed syntax, well, besides being a new syntax =P, it's
not clear because is not the key which will be replaced for a default
value, the default value "else" clause should be outside the [] (if a new
syntax is wanted), which I think is hard to do.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
HOMBRE DESNUDO AMENAZA A LOS VECINOS CON UNA "KATANA" DESDE SU BALCON
	-- Crónica TV
Jan 25 2008
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 1/25/08, Leandro Lucarella <llucax gmail.com> wrote:

 I think your proposed syntax ... it's
 not clear


I'm not proposing a syntax, I'm proposing an idea. I don't care about
the syntax. At least, so long as it's not

    ((p = (key in aa)) is null) ? *p : defaultValue)

:-)
Jan 25 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 1/25/08, Janice Caron <caron800 googlemail.com> wrote:

     ((p = (key in aa)) is null) ? *p : defaultValue)


Spot the deliberate (ahem) mistake! Hint - there's a missing
exclamation mark somewhere. :-)

Seriously, really I just want aa[key] to return some default value.
Whether that's value.init, or some settable property within AAs, or if
it could somehow be expressed at the call site - any or all of those
options would be fine.
Jan 25 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:

 On 1/25/08, Janice Caron <caron800 googlemail.com> wrote:

     ((p = (key in aa)) is null) ? *p : defaultValue)


 
 Spot the deliberate (ahem) mistake! Hint - there's a missing
 exclamation mark somewhere. :-)
 
 Seriously, really I just want aa[key] to return some default value.
 Whether that's value.init, or some settable property within AAs, or if
 it could somehow be expressed at the call site - any or all of those
 options would be fine.


Oskar gave you a solution.

T get(T,U)(T[U] aa, U key) {
         T* ptr = key in aa;
         if (ptr)
                 return *ptr;
         return T.init;
}

T get(T,U,int dummy=1)(T[U] aa, U key, lazy T defaultValue) {
         T* ptr = key in aa;
         if (ptr)
             return *ptr;
            return defaultValue;
}


Which looks exactly like a D translation of Python's get method for dicts.

Python also has setdefault, which does the same as get() but also sets 
the value to the specified default if it didn't exist before.  I'm not 
wild about that name "setdefault" but anyway having the method in the 
std lib is good.

T setdefault(T,U)(T[U] aa, U key) {
         T* ptr = key in aa;
         if (ptr)
                 return *ptr;
         aa[key] = T.init;
         return T.init;
}

T setdefault(T,U,int dummy=1)(T[U] aa, U key, lazy T defaultValue) {
         T* ptr = key in aa;
         if (ptr)
             return *ptr;
         aa[key] = defaultValue
         return aa[key];
}


--bb
Jan 25 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 1/25/08, Janice Caron <caron800 googlemail.com> wrote:

 But yeah - under the first idea, if you really need to tell whether
 the key was present and the value was init, you'd just do

     key in init

 i.e. no change. Existing code still does the job.


Typo. I meant

    key in aa
Jan 25 2008
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Janice Caron Wrote:


 The big problem for me with associative arrays is that I often have to
 write ugly code like:
 [snip]
 if the key was not present in the array? Or perhaps an even more
 exotic syntax like
 
     auto val = aa[key; defaultValue];
 
 might work.


If the behavior is defined at the location of the index call, I'd be very happy
with adding exotic syntax similar to what you propose.  Another candidate would
be to make behavior with invalid indexing a policy that's included in the AA
definition.
Jan 25 2008