In article <d9kq6l$17gq$1@digitaldaemon.com>, Dawid =?ISO-8859-2?Q?Ci=EA=BFarkiewicz?= says...
>>I can't find a thread with the decision about !in.
Now that we have !is I don't see why not. Though the usage would be a bit odd consdiering 'in' returns a pointer.
Sean

Sean Kelly wrote:
> Now that we have !is I don't see why not. Though the usage would be a bit odd consdiering 'in' returns a pointer.
Yes. Despite the fact IMO the compiler should take care about double lookup when using 'in' - not the programer - '!in" keyword has nothing to return but bool so should be very natural addition do language (it will be more natural than custom 'in' ;-) ).
So, should I think:
assert("!in" in D);
?
--
Dawid Ciężarkiewicz | arael

On Sun, 26 Jun 2005 16:22:17 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> In article <d9m711$2mcb$1@digitaldaemon.com>, Dawid
> =?ISO-8859-2?Q?Ci=EA=BFarkiewicz?= says...
>>>> Sean Kelly wrote:
>>> Now that we have !is I don't see why not. Though the usage would be a bit
>>> odd consdiering 'in' returns a pointer.
>>>> Yes. Despite the fact IMO the compiler should take care about double lookup
>> when using 'in' - not the programer - '!in" keyword has nothing to return
>> but bool so should be very natural addition do language (it will be more
>> natural than custom 'in' ;-) ).
>>>> So, should I think:
>> assert("!in" in D);
>> What I'd like is this:
>> int[int] aa;
> int* val;
> if( 5 in aa ) // 'in' returns bit
> if( 5 !in aa ) // '!in' returns bit
> if( ( val = aa[5] ) != null ) // rvalue subscript returns ptr but no insert
> val = ( aa[5] = 6 ); // lvalue subscript does insert and returns ptr
What I'd like is:
int[int] aa;
int val;
if (5 in aa) //'in' returns bit
if (5 !in aa) //'!in' returns bit
if (aa.contains(5,val)) //contains returns bit, assigns val if present
aa[5] = val = 6;
It would also make sense to have the alternate form of contains:
if (aa.contains(5)) //contains returns bit
even if it's identical to 'in' in nature. Or perhaps we keep 'in' as it currently is, returning a pointer. I know I won't be using it (desire to avoid pointers whereever possible).
If however 'in' remains as it currently is, I can write myself the 2 contains routines. I can even write them as templates, however without implicit template instantiation the calls look like:
if (contains!(int)(aa,5))
if (contains!(int)(aa,5,val))
It would be nice if the form matched the calls above. I can't recall.. it might already be possible to use:
if (aa.contains!(int)(5))
if (aa.contains!(int)(5,val))
but it's not quite perfect even so.
Regan

In article <d9mu5u$40c$1@digitaldaemon.com>, Chris Sauls says...
>>> val = ( aa[5] = 6 ); // lvalue subscript does insert and returns ptr
>I dunno. Its a consistancy thing, really I guess. In almost all other places, the value of an assignment is not a pointer. (Pointer typed variables not withstanding.) I don't think I would ever remember to dereferance AA assignments. Well no, I guess I'd learn after a few weeks of fighting the compiler about it... but still.
Unless we get reference types I think returning a pointer makes the best sense :p Though I agree it's a tad odd.
Sean