| Thread overview | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 01, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Thu, Jan 01, 2015 at 01:42:45PM -0500, Steven Schveighoffer via Digitalmars-d wrote: > On 12/31/14 6:05 PM, Dicebot wrote: > >On Wednesday, 31 December 2014 at 22:58:57 UTC, H. S. Teoh via Digitalmars-d wrote: > >>people demanded Tuple support. > > > >Was it bearophile? :P I can't stop feeling that it is simply not recognized enough how bad D tuples are if such request arises. I'd personally try to avoid those in almost all cases where it is practically feasible. > > Right now, ranges properly work with phobos ONLY if they are tuples (specifically std.typecons.Tuple). The idea is that eventually there will be more support for builtin tuples, and at that point, the requirement will shift to the builtin tuple. > > The "fear" is that if you have .key and .value support, and somehow this is impossible to support and also support builtin tuples (I highly doubt this), then we wouldn't be able to use builtin tuples as a return type for aa.byPair.front. Thereby making AA's incompatible with phobos ranges. > > IMO, having SOMETHING in AA.byPair is better than nothing. I really am not worried at all about range tuple support, and I think it will be doable when "real tuples" arrive -- support will be additive. > > And I'm also with you that if you don't have .key .value support, this isn't worth having. [...] The way I see it, this is an acceptable compromise: 1) Have .byKeyValue in druntime, which returns a struct with .key and .value; 2) Have .byPair in Phobos (via UFCS), which wraps around .byKeyValue and returns a Tuple of .key and .value. T -- Question authority. Don't ask why, just do it. | |||
January 02, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | "H. S. Teoh via Digitalmars-d" wrote in message news:mailman.3979.1420139660.9932.digitalmars-d@puremagic.com... > The way I see it, this is an acceptable compromise: > > 1) Have .byKeyValue in druntime, which returns a struct with .key and > .value; > > 2) Have .byPair in Phobos (via UFCS), which wraps around .byKeyValue and > returns a Tuple of .key and .value. I agree with this. | |||
January 02, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 1/1/15 2:12 PM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jan 01, 2015 at 01:42:45PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> And I'm also with you that if you don't have .key .value support, this
>> isn't worth having.
> [...]
>
> The way I see it, this is an acceptable compromise:
>
> 1) Have .byKeyValue in druntime, which returns a struct with .key and
> ..value;
>
> 2) Have .byPair in Phobos (via UFCS), which wraps around .byKeyValue and
> returns a Tuple of .key and .value.
You don't need to wrap, just reimplement (The _aaRange primitives are accessible, I tried it). I don't see any reason to nest these, and they can be unrelated. As I said before, you can shoehorn the primitives into whatever you want in Phobos.
So I'm more interested in getting the .byKeyValue, we can call it that if people like it better. I don't care at all what, if anything, goes into Phobos.
-Steve
| |||
January 02, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | "Steven Schveighoffer" wrote in message news:m862b3$230o$1@digitalmars.com... > You don't need to wrap, just reimplement (The _aaRange primitives are accessible, I tried it). I don't see any reason to nest these, and they can be unrelated. As I said before, you can shoehorn the primitives into whatever you want in Phobos. You should wrap, unless we want to make _aaRange part of the stable api. | |||
January 02, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On 1/2/15 7:40 AM, Daniel Murphy wrote:
> "Steven Schveighoffer" wrote in message
> news:m862b3$230o$1@digitalmars.com...
>
>> You don't need to wrap, just reimplement (The _aaRange primitives are
>> accessible, I tried it). I don't see any reason to nest these, and
>> they can be unrelated. As I said before, you can shoehorn the
>> primitives into whatever you want in Phobos.
>
> You should wrap, unless we want to make _aaRange part of the stable api.
Why, because phobos developers aren't aware of druntime's activities?
-Steve
| |||
January 02, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On Friday, 2 January 2015 at 12:40:41 UTC, Daniel Murphy wrote:
>
> You should wrap, unless we want to make _aaRange part of the stable api.
Yep, please don't rely on runtime internals.
Wrapping front can be inlined and optimized.
| |||
January 02, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On 1/2/15 8:24 AM, Martin Nowak wrote:
> On Friday, 2 January 2015 at 12:40:41 UTC, Daniel Murphy wrote:
>>
>> You should wrap, unless we want to make _aaRange part of the stable api.
>
> Yep, please don't rely on runtime internals.
> Wrapping front can be inlined and optimized.
Well, as I said, I couldn't care less about Phobos implementation :) As long as it's as fast, wrap away.
-Steve
| |||
January 02, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | "Steven Schveighoffer" wrote in message news:m86645$26iu$1@digitalmars.com... > Why, because phobos developers aren't aware of druntime's activities? Ideally, yes. | |||
January 02, 2015 Re: compile-time opIndex | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On 1/2/15 12:37 PM, Daniel Murphy wrote:
> "Steven Schveighoffer" wrote in message
> news:m86645$26iu$1@digitalmars.com...
>
>> Why, because phobos developers aren't aware of druntime's activities?
>
> Ideally, yes.
Nobody from phobos or druntime can commit changes that break the other accidentally.
But, it's not really important to me how the phobos range looks, so I'll drop the argument.
-Steve
| |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply