View mode: basic / threaded / horizontal-split · Log in · Help
June 25, 2005
Is !in planed?
I can't find a thread with the decision about !in.
-- 
Dawid Ciężarkiewicz | arael
June 26, 2005
Re: Is !in planed?
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
Re: Is !in planed?
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
Re: Is !in planed?
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
Re: Is !in planed?
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
Re: Is !in planed?
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
Re: Is !in planed?
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
Re: Is !in planed?
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
Re: Is !in planed?
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
Top | Discussion index | About this forum | D home