May 05, 2012
On Saturday, May 05, 2012 05:50:26 Era Scarecrow wrote:
> > On Saturday, 5 May 2012 at 03:32:06 UTC, Jonathan M Davis wrote:
> >> ---------
> >> Func­tions are over­loaded based on how well the ar­gu­ments to a func­tion can match up with the pa­ra­me­ters. The func­tion with the  best match is se­lected. The lev­els of match­ing are:
> >> 
> >> 1. no match
> >> 2. match with im­plicit con­ver­sions
> >> 3. match with con­ver­sion to const
> >> 4. exact match
> >> ---------
> 
> Hmm maybe it should have a preference for Lvalue vs Rvalue... So... Walter or Andrei?
> 
>   1. no match
>   2. match with im­plicit con­ver­sions (Lvalue required)
>   3. match with con­ver­sion to const (Lvalue required)
>   4. match with im­plicit con­ver­sions
>   5. match with con­ver­sion to const
>   6. exact match

This will likely be _very_ relevant to the proposed changes which make ref and const ref work with rvalues (the details on that are still being sorted out, I believe). However, I don't believe that either Walter or Andrei pays attention to D.Learn, so if you want to bring it up for discussion, post about it in the main newsgroup (not to mention, your post is buried enough in this thread that many who _do_ pay attention to D.Learn wouldn't see it).

- Jonathan M Davis
May 05, 2012
On Saturday, 5 May 2012 at 04:15:21 UTC, Jonathan M Davis wrote:
> On Saturday, May 05, 2012 05:50:26 Era Scarecrow wrote:

>> Hmm maybe it should have a preference for Lvalue vs Rvalue...
>> So... Walter or Andrei?
>> 
>>   1. no match
>>   2. match with im­plicit con­ver­sions (Lvalue required)
>>   3. match with con­ver­sion to const (Lvalue required)
>>   4. match with im­plicit con­ver­sions
>>   5. match with con­ver­sion to const
>>   6. exact match
>
> This will likely be _very_ relevant to the proposed changes  which make ref and const ref work with rvalues (the details on that are still  being sorted out, I believe). However, I don't believe that either Walter or Andrei  pays attention to D.Learn, so if you want to bring it up for discussion, post  about it in the main newsgroup (not to mention, your post is buried enough in  this thread that many who _do_ pay attention to D.Learn wouldn't see it).

 Your probably right.. Thanks, I'll repost this portion over there, I think I saw a topic already present that was this (or closely related) to this.


May 05, 2012
On Saturday, May 05, 2012 05:43:43 Era Scarecrow wrote:
> On Saturday, 5 May 2012 at 03:32:06 UTC, Jonathan M Davis wrote:
> > If you've declared an opAssign, I'd be very surprised if _any_ assignment worked which didn't work with the opAssign that you declared.  Once you've declared an opAssign, you've taken over the assignment  operator, and you need to define it for all of the types that you want it to work with.
> 
>   So define all four... gotcha...

You need to define enough that you can pass any X to one of them. Generally, you probably just need opAssign(const X) and opAssign(const ref X), but since you're trying to have more particular semantics about whether resources get transferred or not, you may need all four.

> > According to http://dlang.org/function.html:
> > 
> > ---------
> > Func­tions are over­loaded based on how well the ar­gu­ments to a func­tion can match up with the pa­ra­me­ters. The func­tion with the  best match is se­lected. The lev­els of match­ing are:
> > 
> > 1. no match
> > 2. match with im­plicit con­ver­sions
> > 3. match with con­ver­sion to const
> > 4. exact match
> > ---------
> > 
> > It picks opAssign(X) over opAssign(ref const X) with an
> > argument of type X,because opAssign(X) is an exact match (#4)
> > whereas opAssign(ref const X)requires a conversion to const
> > (#3).
> 
>   I guess there's one question left. Where does the struct live?
> If it closes at ending of the scope I believed that meant the
> stack, but then this would be illegal:
> 
> ref X func() {
>    return X(new ubyte[5]); //reference to local variable!
> }
> 
>   If it lives on the heap too rather than the stack, that'd good
> to know. I don't recall it specifying in TDPL, but it would be
> easy enough to assume it does (Coming from C).

That code _should_ be illegal. It's as bad as

X* func()
{
    X x;
    return &x;
}

I think that there's an enhancement request about making it an error like my example is, but I can't find it at the moment. Temporaries definitely go on the stack.

- Jonathan M Davis
May 05, 2012
On Saturday, 5 May 2012 at 04:15:21 UTC, Jonathan M Davis wrote:

> This will likely be _very_ relevant to the proposed changes  which make ref and const ref work with rvalues (the details on that are still  being sorted out, I believe). However, I don't believe that either Walter or Andrei  pays attention to D.Learn, so if you want to bring it up for discussion, post  about it in the main newsgroup (not to mention, your post is buried enough in  this thread that many who _do_ pay attention to D.Learn wouldn't see it).

TDPL pg. 145

1) If there's one exact match, take that
2) Select a set of candidates that would accept the call if no other overloads are present. Here is where type deductions deduces types and if clauses are evaluated.
3) If the set has size zero, issue "no match" error.
4) If all functions are not in the same module, issue "attempt at cross-module overloading" error.
5) From that set eliminate all functions that are less specialized than any others in the set; that is, keep only the most specialized functions.
6) If the remaining set has size greater than one, issue "ambiguous call" error
7) The sole element of the set is the winner.

void transmogrify(uint){}
void transmogrify(long){}

... the first is more specialized so it is entitled to win.

--

 I get the feeling the 'ref' in our current discussion isn't being considered as how specialized it is (step 5). Maybe, but it's something to comment on. We'll see what Walter/Andrei have to say. my proposed Lvalue required steps are likely a better help than the rest of this though.
1 2 3
Next ›   Last »