Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dawid Ciężarkiewicz | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dawid Ciężarkiewicz | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Sauls | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Sauls | 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 |
Copyright © 1999-2021 by the D Language Foundation