interesting...

void[int] x; // set declaration

void main()
{
	x[1]; // add element '1' to set
	if (1 in x != null) printf("1 in set");
}

currently it works.
but, are there any warranty that compiler do not remove x[1] expression?

On Mon, 06 Jun 2005 14:19:52 +1100, Ilya Zaitseff wrote:

> interesting...
> 
> void[int] x; // set declaration
> 
> void main()
> {
> 	x[1]; // add element '1' to set
> 	if (1 in x != null) printf("1 in set");
> }
> 
> currently it works.
> but, are there any warranty that compiler do not remove x[1] expression?

This looks like a neat way to create sets. I normally use 'bool[int]' to do the same.

-- 
Derek
Melbourne, Australia
6/06/2005 1:24:42 PM

Very interesting.  I would like some way to have a void value hash... basically just a btree, where missing is the same as false.

I wonder if it takes memory for the values anyway?  Probably does.

-[Unknown]


> interesting...
> 
> void[int] x; // set declaration
> 
> void main()
> {
>     x[1]; // add element '1' to set
>     if (1 in x != null) printf("1 in set");
> }
> 
> currently it works.
> but, are there any warranty that compiler do not remove x[1] expression?

"Ilya Zaitseff" <sark7@mail333.com> wrote in message news:op.srxh7egpaaezs2@ilya.tec.amursk.ru...
> interesting...
>
> void[int] x; // set declaration
>
> void main()
> {
> x[1]; // add element '1' to set
> if (1 in x != null) printf("1 in set");
> }
>
> currently it works.
> but, are there any warranty that compiler do not remove x[1] expression?

That's going away in the next release, due to popular revulsion at the idea that referencing a non-existent key in an associative array would implicitly add it.

"Walter" <newshound@digitalmars.com> wrote in message news:d80rpv$2p85$4@digitaldaemon.com...
>
> "Ilya Zaitseff" <sark7@mail333.com> wrote in message news:op.srxh7egpaaezs2@ilya.tec.amursk.ru...
>> interesting...
>>
>> void[int] x; // set declaration
>>
>> void main()
>> {
>> x[1]; // add element '1' to set
>> if (1 in x != null) printf("1 in set");
>> }
>>
>> currently it works.
>> but, are there any warranty that compiler do not remove x[1] expression?
>
> That's going away in the next release, due to popular revulsion at the
> idea
> that referencing a non-existent key in an associative array would
> implicitly
> add it.
>
>

Just as an idea:
In my implementation of Dictionary (wrapper around map) I am using
additional
forms:

VALUE opIndex(KEY key, VALUE delegate(KEY k) ctor)
VALUE opIndex(KEY key, VALUE function(KEY k) ctor)

Additional parameter allows to construct value on the fly if it does not
exist effectively
as there are cases (e.g. implementation of String.intern in Java) where it
is nice to have feature.

And of course:
const void[int] x;  //eh?

In article <d80rpv$2p85$4@digitaldaemon.com>, Walter says...
>
>
>"Ilya Zaitseff" <sark7@mail333.com> wrote in message news:op.srxh7egpaaezs2@ilya.tec.amursk.ru...
>> interesting...
>>
>> void[int] x; // set declaration
>>
>> void main()
>> {
>> x[1]; // add element '1' to set
>> if (1 in x != null) printf("1 in set");
>> }
>>
>> currently it works.
>> but, are there any warranty that compiler do not remove x[1] expression?
>
>That's going away in the next release, due to popular revulsion at the idea that referencing a non-existent key in an associative array would implicitly add it.

I actually like this :p  But I suppose it's because I'm used to the behavior of std::map in C++.


Sean

In article <d80rpv$2p85$4@digitaldaemon.com>, Walter says...
>
>
>"Ilya Zaitseff" <sark7@mail333.com> wrote in message news:op.srxh7egpaaezs2@ilya.tec.amursk.ru...
>> interesting...
>>
>> void[int] x; // set declaration
>>
>> void main()
>> {
>> x[1]; // add element '1' to set
>> if (1 in x != null) printf("1 in set");
>> }
>>
>> currently it works.
>> but, are there any warranty that compiler do not remove x[1] expression?
>
>That's going away in the next release, due to popular revulsion at the idea that referencing a non-existent key in an associative array would implicitly add it.

(I thought the current behavior was weird when I first saw it in C++.  I'm used to it now, but if it changes that's okay.)

What replaces the current behavior?  Do you get an exception from T[unknown], or just T.init?

The C++ way seems to make sense in C++, since I can store a C++ reference to an object and then avoid a second lookup for the insertion phase.  In D you can't store a mutable reference (as far as I know), unless maybe with:

T * xp = & x[i];

Does this work now (it seems to, with int[char[]]), would it still work, or
would there still be a way to avoid the second lookup for the "if (i !in
container) { container[i] = 100; }"?

I guess I'm back to proposing opIndexMutable() or similar... It seems like "writeable" cases such as the above could use the (current) "x[i] = T.init" semantics if not present.  Likewise for passing to inout parameters.

FWIW, I don't mind if "second lookup avoidance" is a little more awkward syntax wise since its only an optimization.  The current mechanism probably leads many people to do two lookups, either with "in" then "x[i]=" or another similar two-step.

One syntax might be:

x.lookup(i): returns "T*".

Sorry if it seems like you're getting fired on from both camps...

Kevin