gmane.comp.lang.d.dmd.beta

Re: D 1.074 and 2.059 betas

Dmitry Olshansky — 2012-05-22T17:28:44

+11

Re: D 1.074 and 2.059 betas

David Nadlinger — 2012-05-22T17:12:02

Well, ideally yes – but on the other hand, changelog entries are 
usually left out of pull requests to avoid merging errors.

This issue has already been raised and discussed multiple times. Maybe 
we can finally find a clever way to keep the changelog separately, but 
still tied to version control. An idea that pops to my mind would be a 
simple table (e.g. in the form of a tiny web app) where people can post 
changelog messages along with a Git commit hash. When preparing the 
release, a script is run to query the list for all new commit IDs. If a 
matching messages is found, it is added to the changelog, otherwise a 
»changelog entry missing« warning is printed for that commit.

Hm, on the second thought, it might be much more safe and less work to 
just stick the changelog entries in the commit messages (in some 
agreed-on format, e.g. a DDoc-like »Changelog:« section), and simply 
accumulate them with a little script when preparing the release. Again, 
commits not including a message could conven

Re: D 1.074 and 2.059 betas

Andrei Alexandrescu — 2012-05-22T16:58:14

I'm replying this with delay as I'm working out of my email debt.

Nick, what we usually do is each contributor takes care of the changelog 
when fixing an error. Could you please insert a line for each of these 
in next version's changelog (possibly with a note that they've been 
fixed a release ago)?


Thanks,

Andrei

On 4/5/12 5:55 AM, Nick Sabalausky wrote:

Re: rvalue references

Andrei Alexandrescu — 2012-04-16T21:48:20

Walter convinced me a while ago that transparent pass by ref is 
problematic. Consider:

struct S < at >pass_by_ref(true)
{
    ...
}

void fun(T)(T a, T b)
{
    ...
}

Inside fun, code is free to assume that &a != &b with quite important 
consequences. If calling fun(s, s) ends up aliasing the two names to the 
same thing, it will fail in difficult to figure ways.


Andrei

Re: rvalue references

Michel Fortin — 2012-04-16T21:21:43

Le 2012-04-16 à 14:31, Sean Kelly a écrit :


The compiler can't decide by itself because there is not enough context, it also pose some problems for having a stable ABI. That said, I agree that having to add ref (or auto-ref) everywhere for efficiency isn't very appealing.

Did you notice the "ref struct" proposal I made a while ago on the newsgroup? Basically you attach a flag to a struct declaration that'd cause that struct to be automatically passed by ref when used as a function argument. It's crude, but it'd be much less verbose than writing 'ref' or 'auto ref' everywhere.

Re: rvalue references

Jason House — 2012-04-16T20:59:03


Scope isn't implemented for anything but delegates. If something is const and no references are escaped, then both a copy and pass by reference can serve the same purpose.

Re: rvalue references

Jonathan M Davis — 2012-04-16T20:48:52

scope prevents escaping references (or is supposed to anyway - I don't think 
that it actually does right now), and in the case of delegates, it allows the 
compiler to avoid allocating a closure. It's really only applicable to 
reference types, so no copying would be occuring anyway. The issue is when you 
have value types that you don't necessarily want to copy.

- Jonathan M Davis

Re: rvalue references

Jason House — 2012-04-16T18:57:08


I believe "const scope" arguments would fall into the category of not caring if a copy was made or not.

Re: rvalue references

Sean Kelly — 2012-04-16T18:29:38


Sure… as long as you're sure "foo" is a static array.  But if it's an alias that the spec allows to be an opaque type...

Re: rvalue references

Jonathan M Davis — 2012-04-16T18:43:16

In many cases, the compiler can't know when a copy is actually required. If 
there's a way for the programmer to indicate that they don't care whether a 
copy is made or not, letting the compiler decide, then that solves the problem 
(which was the idea behind auto ref). Without that though, the compiler will 
have to assume that a copy has to be made in cases where it doesn't. And 
actually, since without auto ref, there's no way to overload a function such 
that the compiler chooses ref or non-ref based on what it thinks is the most 
efficient, I don't see how the compiler could elide copies except in cases where 
inlining eliminates the function call entirely. We need a way for the 
programmer to be able to tell the compiler that they don't care whether the 
argument is passed by ref or not. Barring that, making it possible for const 
ref (and possibly ref) to take rvalues is probably the best that we can do.

- Jonathan M Davis

Re: rvalue references

Steve Schveighoffer — 2012-04-16T18:38:14

Well, there are many times I'd rather have 'this' passed by value for efficiency!

Const ref would fit the bill nicely, if it didn't affect the type.


What would be interesting is if there was a way to say "this won't change in this function", and then the compiler could choose to pass by ref or value depending on which was more efficient, while still enforcing the property that the value doesn't change.

Hm.. could there be a library solution?


-Steve




dmd-beta mailing list
dmd-beta< at >puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Re: rvalue references

Sean Kelly — 2012-04-16T18:31:19

Ideally, no one should ever specify "ref" simply for efficiency.  The programmer should choose semantics for logical reasons, and leave optimization up to the compiler.  That may still not be practical however.

Re: rvalue references

Steve Schveighoffer — 2012-04-16T13:32:55

Disallowing property results to bind to ref is not a good solution IMO.  Note that one of the *worst* problems with rvalue/lvalue ref semantics right now is operator overloading.  Frequently, one may want to pass by ref for overloading arithmetic operations or other operators due to the size of the struct.  But then simple combining operations like a + (b - c) don't work.

Note that this varies *greatly* with the issue of the compiler doing implicit casting.  In the compiler's case, it's creating behind-the-scenes temporaries that you cannot see or access.  But in the case of the return value of a function or property, everything is spelled out in the declaration of the function or property.

I think part of our issue here is, there are multiple reasons to pass by ref.  So it's difficult to establish the correct rules.

My thought is, we need different markers for different situations.  I don't think one keyword is enough.

What 'auto ref' was supposed to do was allow both rvalue and lvalue binding.

Re: rvalue references

Jonathan M Davis — 2012-04-16T00:29:20

It was my understanding that you arrays in C are _always_ passed as a pointer 
and that even if you use [] instead of * on the parameter, it's the same as 
using * and that there was no way to specifically pass a static array 
differently from a dynamic one. But I may remember that incorrectly, since I 
almost never use static arrays.

If I'm right though, then fn will just always take an int*.

- Jonathan M Davis

Re: rvalue references

Sean Kelly — 2012-04-15T16:07:03


The problem is mostly with stuff like:

extern (C):
alias int[2] foo;
void fn(foo);

Now make the alias platform-dependent (as in the Posix package) and tell me what the prototype for fn() should be. Fortunately, static array args are almost nonexistent in C99 and Posix.

Re: rvalue references

Andrei Alexandrescu — 2012-04-15T04:11:18

I think it's a good way to look at it, but there's sometimes something
like this: "This function doesn't care rvalue vs. lvalue, but doesn't
want to mess with const and would prefer pass by ref wherever possible
for efficiency reasons."


Correct. One detail is that basic literals are obviously not modifiable
at the call site: foo(2, 3.4) is visibly unable to modify its arguments.
But then, in fairness, foo(a, b) is more confusing if a and b are enum
values.


Fine.


So far so good.


This makes sense, but there are two issues:

1. How about generic code? Generic code should have a "use the most
efficient passing convention for this argument, I'm okay with either
value or reference".

2. What if the rvalue is the result of calling a function? Does it bind
to mutable ref or not?

It became clear to me that Walter and my initial proposal is not good.
But I'm not sure we have a clear and simple vision yet.



Andrei

Re: rvalue references

Andrei Alexandrescu — 2012-04-15T03:42:14

This part of the proposal is sound but I fear it could cause confusion.
It is a special rule, and special rules may be surprising.

Also I don't know when people have bugs because of it. I mean when is
the last time anyone called swap(10, 20)?

Let me see the second part.


Andrei

On 4/13/12 12:58 AM, kenji hara wrote:

Re: ref semantics

Andrei Alexandrescu — 2012-04-15T03:36:02

I hate this problem. It makes the necessary analysis quite a bit more 
complicated and less precise. Essentially most functions that take a ref 
to a local and return a ref must be analyzed for the possibility they 
return the argument.

Let me look over Kenji's proposal, hopefully it takes care of this 
automatically :o).

Andrei

Re: rvalue references

Jonathan M Davis — 2012-04-13T20:48:25

Which seems really backwards considering that in both case, you'd be using T* 
in C, and if anything, dynamic arrays are closer to that than static arrays. 
Personally, I'd have expected arr.ptr to be required in both cases.

- Jonathan M Davis

Re: rvalue references

Don Clugston — 2012-04-13T20:18:16

Interestingly, the ref int[3] idiom is documented as working, under
'interfacing with C'.
Anything beyond that seems to be undefined.
That page seems to document dynamic arrays as _not_ working --
certainly as having no C equivalent.

Re: rvalue references

Andrei Alexandrescu — 2012-04-13T18:40:20

I'm busy right now, give me some time to look over it.

Thanks,

Andrei

On 4/13/12 1:39 PM, kenji hara wrote:
_______________________________________________
dmd-beta mailing list
dmd-beta< at >puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta