Jump to page: 1 28  
Page
Thread overview
My Kingdom For ...
Feb 20, 2008
Darryl Bleau
Feb 21, 2008
Moritz Warning
Feb 21, 2008
Bill Baxter
Feb 21, 2008
Darryl Bleau
stable != abandoned [was: My Kingdom For ...]
Feb 21, 2008
Leandro Lucarella
Feb 21, 2008
Bill Baxter
Feb 22, 2008
Christopher Wright
Feb 22, 2008
Leandro Lucarella
Feb 23, 2008
Christopher Wright
Feb 21, 2008
Gregor Richards
Feb 21, 2008
bearophile
Feb 21, 2008
Darryl Bleau
Feb 21, 2008
Moritz Warning
Feb 22, 2008
Robert Fraser
Feb 22, 2008
Bill Baxter
Feb 22, 2008
Moritz Warning
Feb 22, 2008
Gregor Richards
Feb 23, 2008
Darryl Bleau
Feb 23, 2008
Alexander Panek
Feb 21, 2008
Janice Caron
Feb 21, 2008
Ary Borenszweig
Feb 22, 2008
Christopher Wright
Feb 21, 2008
Leandro Lucarella
Feb 21, 2008
Darryl Bleau
Feb 21, 2008
Matti Niemenmaa
Feb 22, 2008
Robert Fraser
Feb 21, 2008
Robert Fraser
Feb 21, 2008
Robert Fraser
Feb 21, 2008
Bill Baxter
Feb 22, 2008
Christopher Wright
Feb 21, 2008
Darryl Bleau
Feb 21, 2008
Janice Caron
Feb 21, 2008
Bill Baxter
Feb 21, 2008
Janice Caron
Feb 21, 2008
Bill Baxter
Feb 21, 2008
Ary Borenszweig
Feb 21, 2008
Janice Caron
Feb 21, 2008
Ary Borenszweig
Feb 21, 2008
Janice Caron
Feb 21, 2008
Ary Borenszweig
Feb 21, 2008
Derek Parnell
Feb 21, 2008
Janice Caron
Feb 22, 2008
Janice Caron
Feb 22, 2008
Dan
Feb 22, 2008
Derek Parnell
Feb 22, 2008
Janice Caron
Feb 22, 2008
Don Clugston
Feb 22, 2008
Derek Parnell
Feb 24, 2008
Don Clugston
Feb 24, 2008
Janice Caron
Feb 24, 2008
Janice Caron
Feb 24, 2008
Don Clugston
Feb 22, 2008
Bill Baxter
Feb 22, 2008
Derek Parnell
Feb 22, 2008
Janice Caron
Feb 22, 2008
Bill Baxter
Feb 22, 2008
Janice Caron
Feb 22, 2008
Brad Roberts
Feb 22, 2008
Robert Fraser
February 20, 2008
opIndexConcat
opIndexConcatAssign

in D1, of course.

I would also potentially accept:

Returning static arrays from functions.

or, possibly:

!in
February 21, 2008
"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.

ref returns are planned in D2.  I'd also like !in but that issue's been discussed _so_ many times before..


February 21, 2008
On Wed, 20 Feb 2008 20:56:59 -0500, 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.
> 
> ref returns are planned in D2.  I'd also like !in but that issue's been discussed _so_ many times before..

Is there a FAQ about common feature requests?
Yes, that's a feature request, too. :)
February 21, 2008
Moritz Warning wrote:
> On Wed, 20 Feb 2008 20:56:59 -0500, 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.
>>
>> ref returns are planned in D2.  I'd also like !in but that issue's been
>> discussed _so_ many times before..
> 
> Is there a FAQ about common feature requests?
> Yes, that's a feature request, too. :)

And it's also a FAQ.  How 'bout that? :)

--bb
February 21, 2008
/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.

 - Gregor Richards
February 21, 2008
"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:fpin5l$121l$1@digitalmars.com...

>>
>> Is there a FAQ about common feature requests?
>> Yes, that's a feature request, too. :)
>
> And it's also a FAQ.  How 'bout that? :)

My head just exploded from the recursion.


February 21, 2008
Darryl Bleau wrote:
> opIndexConcat
> opIndexConcatAssign

Maybe it's the 5 AM thing, but I'm feeling pretty stupid right now. What would these do?

> in D1, of course.

Not happening. D2, maybe.

> I would also potentially accept:
> 
> Returning static arrays from functions.

Wrap it in a struct. What's your use case for this, anyway?

> or, possibly:
> 
> !in

Gregor's post sums up my thoughts on the issue.
February 21, 2008
"Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:fpjuh5$uai$1@digitalmars.com...
> Darryl Bleau wrote:
>> opIndexConcat
>> opIndexConcatAssign

// Contrived, but shows the issue.
struct IntArray
{
    int[] mData;

    int opIndex(size_t idx)
    {
        return mData[idx];
    }
}

int[] realArray = [1, 2, 3];
realArray[0]++; // now contains [2, 2, 3]

IntArray a;
a.mData = [1, 2, 3];
a[0]++; // FAIL

In other words without these opIndexSomethingAssign overloads or ref returns it's impossible to make a user container type behave just like a built-in one.

(as an aside MiniD solves this by defining "a[0]++" to be "temp = a[0]; temp++; a[0] = temp;" but that's beside the point.)


February 21, 2008
Jarrett Billingsley wrote:
> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:fpjuh5$uai$1@digitalmars.com...
>> Darryl Bleau wrote:
>>> opIndexConcat
>>> opIndexConcatAssign
> 
> // Contrived, but shows the issue.
> struct IntArray
> {
>     int[] mData;
> 
>     int opIndex(size_t idx)
>     {
>         return mData[idx];
>     }
> }
> 
> int[] realArray = [1, 2, 3];
> realArray[0]++; // now contains [2, 2, 3]
> 
> IntArray a;
> a.mData = [1, 2, 3];
> a[0]++; // FAIL
> 
> In other words without these opIndexSomethingAssign overloads or ref returns it's impossible to make a user container type behave just like a built-in one.
> 
> (as an aside MiniD solves this by defining "a[0]++" to be "temp = a[0]; temp++; a[0] = temp;" but that's beside the point.) 

Ah, I see! Ref returns are a more general & overall happier solution, IMO.
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.

It's silly that 'in' does not return a bool. 'in' and '!in' make perfect sense together as boolean operators (as in set theory).

Of course, you want to be able to get the pointer too, but I would suggest a library function for that.

That's readability.

-- 
Michiel

« First   ‹ Prev
1 2 3 4 5 6 7 8