Principled method of lookup-or-insert in associative arrays?

spir denis.spir at gmail.com
Sat Nov 20 08:09:00 PST 2010


On Sat, 20 Nov 2010 15:22:37 +0100
Tomek Sowiński <just at ask.me> wrote:

> > I find this proposal really necessary. But aren't there two issues here?
> > * Comparison (for lookup) by value equality should not care about  
> > qualifiers (ie compare raw content, here plain array memory areas).
> > * Assignment should perform "qualification conversion" automatically, eg
> > 	char[] chars = "abc";
> > 	string s = chars;
> > This involves no implicit magic here, as target qualification is  
> > explicit. So, why not?  
> 
> It's busting the whole const system to smithereens.
> 
> char[] chars = "abc";
> char[] backdoor = chars;
> string s = chars;
> assert (s == "abc");
> backdoor.front = 'k';
> assert (s == "abc"); // fails. not so immutable, huh?

???
backdoor and s do not denote the same element. One is a mutable array, the other is immutable. Why should changing backdoor affect s? Whether backdoor and chars denote the same array depends on whether "=" copies or not dyn arrays. But from immutable string to mutable array, there must be a copy (read: dup).

Anyway, the most annoying issue is not about assignments inside a given scope, but parameter passing (including implicit ones like in Andrei's example of foreach).
	void f (char[] chars) {}
	void g (string str) {}
	...
	string str = "abc";
	char[] chars = "abc".dup;
	f(str);
	g(chars);
__trials__.d(30): Error: function __trials__.f (char[] chars) is not callable using argument types (string)
__trials__.d(31): Error: function __trials__.g (string str) is not callable using argument types (char[])
	...
	f(str.dup);	// ok
	g(chars.idup);	// ditto

> > There is a repetitive programming pattern in D:
> > * play around with *string's in general
> > * as soon as text processing is needed, convert to *char[]
> > * when finished, convert back to *string  
> 
> Meh, immutable strings make life easier.

For sure, I'm 100% for immutable strings by default, esp that literals produce immutable elements. But one cannot perform text processing on immutable thingies:
	s[3] = 'x';
	s.replace("abc","ABC");
So that we constantly have to juggle between mutable and immutable versions of, conceptually, the _same value_.

By the way, why isn't the definition of string immutable(char[]), instead of immutable(char)[]?


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com



More information about the Digitalmars-d mailing list