February 21, 2008
Gregor Richards:
> Walter's argument against !in makes perfect sense, and nobody ever acknowledges that. 'in' is not a boolean operation, and it wouldn't be good for 'in' to return a pointer and '!in' to return a bool. That's just silly.

"in" and "!in" may return both bools.
Another solution is to think "in" as an operator, and "!in" as two operators, where ! negates the result of the precedent "in", where "in" returns a pointer. I don't see this as silly :-)

Bye,
bearophile
February 21, 2008
On 21/02/2008, Michiel Helvensteijn <nomail@please.com> wrote:
> It's silly that 'in' does not return a bool.

Huh? But I don't want it to return a bool. If it retured a bool, I wouldn't be able to do

    auto p = key in aa;
    if (p is null)
    {
        /* do something */
    }
    else
    {
        return *p;
    }

Without that ability, you'd have to do a double-lookup!
February 21, 2008
Janice Caron escribió:
> On 21/02/2008, Michiel Helvensteijn <nomail@please.com> wrote:
>> It's silly that 'in' does not return a bool.
> 
> Huh? But I don't want it to return a bool. If it retured a bool, I
> wouldn't be able to do
> 
>     auto p = key in aa;
>     if (p is null)
>     {
>         /* do something */
>     }
>     else
>     {
>         return *p;
>     }
> 
> Without that ability, you'd have to do a double-lookup!

I think the best solution is the one in .Net:

object value;
if (aa.TryGetValue(key, out value)) {
  // Key found, value may be null
} else {
  // Key not found
}
February 21, 2008
Janice Caron wrote:

> On 21/02/2008, Michiel Helvensteijn <nomail@please.com> wrote:
> 
>> It's silly that 'in' does not return a bool.
> 
> Huh? But I don't want it to return a bool. If it retured a bool, I wouldn't be able to do
> 
>     auto p = key in aa;
>     if (p is null)
>     {
>         /* do something */
>     }
>     else
>     {
>         return *p;
>     }
> 
> Without that ability, you'd have to do a double-lookup!

In those cases you use that library function I mentioned. It would do the exact thing 'in' does now.

When I read: key in aa, I understand: key is member of aa. Like the operator
in set theory (looks like an epsilon). Apparently I'm not alone in this
if !in has been requested so often.

-- 
Michiel

February 21, 2008
Jarrett Billingsley wrote:
> "Darryl Bleau" <user@example.net> wrote in message news:fphle3$20np$1@digitalmars.com...
>> opIndexConcat
>> opIndexConcatAssign
>>
>> in D1, of course.
>>
>> I would also potentially accept:
>>
>> Returning static arrays from functions.
>>
>> or, possibly:
>>
>> !in
> 
> Sorry, no new language features in D1.
> 

I know, and I knew when writing it that it was futile to ask. I suppose I was more just venting my frustration that it seems that D1 was released, and Walter said, 'go forth and create programs', which we did, but now we turn around and say, hey, this D stuff is great, could we just have a few minor changes? But, are denied. Seems Const and Enum are much more important than helping with actual practical applications of the current language.

Perhaps if we were around while D1 was still being developed.. but then, we wouldn't have been using it in that state. Chicken, egg, and all that.

I like D, it's great, and I appreciate all the effort spent on it. I just sort of wish D1 development continued on some level parallel to D2. I wouldn't expect massive changes, but some minor additions would be nice and would help out quite a lot with current usage.
February 21, 2008
Gregor Richards wrote:
> /me boos !in again.
> 
> Walter's argument against !in makes perfect sense, and nobody ever acknowledges that. 'in' is not a boolean operation, and it wouldn't be good for 'in' to return a pointer and '!in' to return a bool. That's just silly.
> 

I don't expect it to return a boolean, I just expect '!' to perform a not operation. That is, I would expect that:

(a !in b)

Would behave the same as:

(!(a in b))

'a in b' can still return the pointer fine, that makes perfect sense.
February 21, 2008
bearophile wrote:
> Another solution is to think "in" as an operator, and "!in" as two operators, where ! negates the result of the precedent "in", where "in" returns a pointer. I don't see this as silly :-)

I should have read this first. Yes, that's exactly what I would like.
February 21, 2008
Robert Fraser wrote:
> Darryl Bleau wrote:
>> opIndexConcat
>> opIndexConcatAssign
> 
> Maybe it's the 5 AM thing, but I'm feeling pretty stupid right now. What would these do?

This was answered and is what I would use them for. To create user containers that operate like built-in ones. I know that there are other, more extensible ways to do this (left references) but I'm just looking for something a little less involved, to help with D1 programming.

It would seem to me that if there is already opIndexAssign that adding a few others like these should probably not be a ton of effort, though that is just an educated guess and I could be wrong. But if it weren't a lot of effort, and only cost a few extra lines of code, it would be nice to have.


>> Returning static arrays from functions.
> 
> Wrap it in a struct. What's your use case for this, anyway?

My particular use case is a logger which can properly use lazy format
parameters without having to do something like log.info("{}"[],
"blah"[]);, which works, and preserves laziness, but isn't exactly friendly.

>> or, possibly:
>>
>> !in
> 
> Gregor's post sums up my thoughts on the issue.

(!(a in b)) == (a !in b) would be all I'm asking.


Don't get me wrong though, I understand completely that none of this will ever happen. I just wish it could. :)
February 21, 2008
Darryl Bleau, el 21 de febrero a las 09:48 me escribiste:
> Jarrett Billingsley wrote:
> > "Darryl Bleau" <user@example.net> wrote in message news:fphle3$20np$1@digitalmars.com...
> >> opIndexConcat
> >> opIndexConcatAssign
> >>
> >> in D1, of course.
> >>
> >> I would also potentially accept:
> >>
> >> Returning static arrays from functions.
> >>
> >> or, possibly:
> >>
> >> !in
> > 
> > Sorry, no new language features in D1.
> > 
> 
> I know, and I knew when writing it that it was futile to ask. I suppose I was more just venting my frustration that it seems that D1 was released, and Walter said, 'go forth and create programs', which we did, but now we turn around and say, hey, this D stuff is great, could we just have a few minor changes? But, are denied. Seems Const and Enum are much more important than helping with actual practical applications of the current language.

I agree. D1.0 looks more "abandoned" than "stable". A language should keep moving even when it's stable, as long as the changes are backward compatibles. That mean that a new syntax that was previosly forbiden or new additions to the standard library could be done without affecting stability.

If Walter don't have the time, maybe, again, it's time to name a successor, someone who has the time to take over like Linus does with the stable kernels.

I know this is extremely difficult with DMD being closed, but maybe he can find a way.

For now, it's like there is no viable D Language, you have D1.0 wich is broken (there are a lot of things specified in the specs that are not implemented in D1.) and gets too little attention, or D2.0 that it's continously evolving and getting huge changes.

I think D1.0 is good enough and deserves a little love to finally polish all the rough corners and make it move forward in small and backward compatible steps to be a nice, maintained and usable language.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Bulletproof... I Wish I Was
February 21, 2008
Janice Caron, el 21 de febrero a las 15:38 me escribiste:
> On 21/02/2008, Michiel Helvensteijn <nomail@please.com> wrote:
> > It's silly that 'in' does not return a bool.
> 
> Huh? But I don't want it to return a bool. If it retured a bool, I wouldn't be able to do
> 
>     auto p = key in aa;
>     if (p is null)
>     {
>         /* do something */
>     }
>     else
>     {
>         return *p;
>     }
> 
> Without that ability, you'd have to do a double-lookup!

What about the Python-way:

     auto p = aa.get(key);
     if (p is null)
     {
         /* do something */
     }
     else
     {
         return *p;
     }

And leave in as a bool operator?
get could take an optional parameter which is the value you want it to
return if the key is not present.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
PROTESTA EN PLAZA DE MAYO: MUSICO SE COSIO LA BOCA
	-- Crónica TV