Thread overview
Is !in planed?
Jun 26, 2005
Sean Kelly
Jun 26, 2005
Sean Kelly
Jun 26, 2005
Chris Sauls
Jun 27, 2005
Sean Kelly
Jun 26, 2005
Regan Heath
Jun 26, 2005
Chris Sauls
Jun 26, 2005
Regan Heath
June 25, 2005
I can't find a thread with the decision about !in.
-- 
Dawid Ciężarkiewicz | arael
June 26, 2005
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


June 26, 2005
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
June 26, 2005
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


Sean


June 26, 2005
Sean Kelly wrote:
> What I'd like is this:
> 
> int[int] aa;
> int* val;
> if( 5 in aa ) // 'in' returns bit
This works currently, as a null pointer is a 'false' value in D.

> if( 5 !in aa ) // '!in' returns bit
> if( ( val = aa[5] ) != null ) // rvalue subscript returns ptr but no insert
This might be nifty-ish.  Currently it throws an exception (ArrayBoundsException) so you could "just" mimic this if/if-else with a try block.

# try {
#   val = aa[5]; // if ((val = aa[5]) !=  null) { }
# }
# catch (ArrayBoundsException abx) {
#   // ... do something else // else { }
# }

I never said it was pretty...

> 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.

-- Chris Sauls
June 26, 2005
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
June 26, 2005
Regan Heath wrote:
> if (aa.contains!(int)(5))
> if (aa.contains!(int)(5,val))

I don't think this works... yet, anyhow.  Although you could do:

# if (contains!(aa)(5))
# if (contains!(aa)(5,val))

-- Chris Sauls
June 26, 2005
On Sun, 26 Jun 2005 17:45:50 -0500, Chris Sauls <ibisbasenji@gmail.com> wrote:
> Regan Heath wrote:
>> if (aa.contains!(int)(5))
>> if (aa.contains!(int)(5,val))
>
> I don't think this works... yet, anyhow.  Although you could do:
>
> # if (contains!(aa)(5))
> # if (contains!(aa)(5,val))

Really? I can't seem to make that happen in a generic way. :(
I assume you'd use 'alias' in the template.

Regan
June 27, 2005
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