View mode: basic / threaded / horizontal-split · Log in · Help
February 20, 2008
My Kingdom For ...
opIndexConcat
opIndexConcatAssign

in D1, of course.

I would also potentially accept:

Returning static arrays from functions.

or, possibly:

!in
February 21, 2008
Re: My Kingdom For ...
"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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
/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
Re: My Kingdom For ...
"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
Re: My Kingdom For ...
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
Re: My Kingdom For ...
"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
Re: My Kingdom For ...
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
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.

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
Top | Discussion index | About this forum | D home