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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Darryl Bleau | "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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Moritz Warning | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Darryl Bleau | /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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | "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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Darryl Bleau | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Fraser | "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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarrett Billingsley | 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 ... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 |
Copyright © 1999-2021 by the D Language Foundation