View mode: basic / threaded / horizontal-split · Log in · Help
February 21, 2008
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
stable != abandoned [was: My Kingdom For ...]
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
Re: My Kingdom For ...
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home