On Saturday, July 06, 2013 11:44:43 TommiT wrote:
> On Saturday, 6 July 2013 at 08:14:06 UTC, Jonathan M Davis wrote:
> > Ah, there's also auto ref. The way TDPL describes it, it should
> > work on the
> > parameters of non-templated functions as well as templated
> > ones, but it has
> > yet to be implemented that way. And there's some debate as to
> > what to do about
> > that.
> 
> TDPL doesn't mention auto ref at all (not even as a function return type). The spec talks about auto ref as both function return type and parameter type for function templates.

Really? Are you sure? I was certain that it did. But it's been a while now since I read it, so I'm not necessarily as clear on what's in it as I used to be. I should probably reread it one of these days, but I don't really have time right now.

> So, it
> seems auto ref as parameter for regular functions doesn't seem to
> documented anywhere (which is good if it's not ready yet).

I know that the original proposal for auto ref was not specifically for templated functions but that Walter misunderstood what Andrei had meant and just implemented them for templated functions (and the implementation used for templated functions wouldn't work with  non-templated ones). It would be trivial to implement auto ref for non-templated functions, and I think that there's a good chance that we will, but there's a some debate over that, primarily because some people think that the term "auto ref" doesn't make sense with what a non-templated function would have to do (which would be to be ref underneath the hood and then assigne rvalues to lvalues on the stack so that they could be passed to the function by ref).

- Jonathan M Davis

On Saturday, July 06, 2013 11:56:43 Namespace wrote:
> > 4. We might be changing it so that member functions are virtual by default
> 
> You mean final by default, don't you? AFAIK they are currently virtual by default.

Yeah. I mean changed to non-virtual / final by default. I mistyped.

- Jonathan M Davis

On Saturday, 6 July 2013 at 09:58:25 UTC, Jonathan M Davis wrote:
> On Saturday, July 06, 2013 11:44:43 TommiT wrote:
>> On Saturday, 6 July 2013 at 08:14:06 UTC, Jonathan M Davis wrote:
>> > Ah, there's also auto ref. The way TDPL describes it, it should
>> > work on the
>> > parameters of non-templated functions as well as templated
>> > ones, but it has
>> > yet to be implemented that way. And there's some debate as to
>> > what to do about
>> > that.
>> 
>> TDPL doesn't mention auto ref at all (not even as a function
>> return type). The spec talks about auto ref as both function
>> return type and parameter type for function templates.
>
> Really? Are you sure?

Yep, 100% sure.

> The current release is 2.063.2, but it's the first time that we've actually
> released point releases like that, so there are likely to be places saying
> 2.063 instead of 2.063.2.

Maybe it's time to make the odd-numbered releases the work in progress releases and the even-numbered releases the official releases?

-<mike>-

On Saturday, 6 July 2013 at 13:24:06 UTC, mike james wrote:
> Maybe it's time to make the odd-numbered releases the work in progress releases and the even-numbered releases the official releases?

What is the point? All releases are official releases, "work in progress" == git master.

On Saturday, 6 July 2013 at 13:26:38 UTC, Dicebot wrote:
> On Saturday, 6 July 2013 at 13:24:06 UTC, mike james wrote:
>> Maybe it's time to make the odd-numbered releases the work in progress releases and the even-numbered releases the official releases?
>
> What is the point? All releases are official releases, "work in progress" == git master.

So you can keep track of the interim releases. Some people like to get their releases from the D website as an install and not from git-hub.

On Saturday, 6 July 2013 at 13:36:41 UTC, mike james wrote:
> So you can keep track of the interim releases. Some people like to get their releases from the D website as an install and not from git-hub.

Released content does not differ from repository one. It only means that exactly this state was tested and expected to work. Unreasonable preferences are not worth extra useless work.

On Sat, 2013-07-06 at 15:24 +0200, mike james wrote:
> > The current release is 2.063.2, but it's the first time that
> > we've actually
> > released point releases like that, so there are likely to be
> > places saying
> > 2.063 instead of 2.063.2.
> 
> Maybe it's time to make the odd-numbered releases the work in progress releases and the even-numbered releases the official releases?

Everyone, cf. Linux, who used to operate such a strategy has now stopped. A release is a release and should be releasable. Finding problems in a release is natural which is why the maj.min.bug release numbering is so popular. The issue here is that the releases should be numbered this way always so as to make a monotonic increasing sequence.

Thus 2.063 should have been numbered 2.63.0.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 7 July 2013 at 07:36:41 UTC, Russel Winder wrote:
> On Sat, 2013-07-06 at 15:24 +0200, mike james wrote:
>> > The current release is 2.063.2, but it's the first time that we've actually
>> > released point releases like that, so there are likely to be places saying
>> > 2.063 instead of 2.063.2.
>> 
>> Maybe it's time to make the odd-numbered releases the work in progress releases and the even-numbered releases the official releases?
>
> Everyone, cf. Linux, who used to operate such a strategy has now
> stopped. A release is a release and should be releasable. Finding
> problems in a release is natural which is why the maj.min.bug release
> numbering is so popular. The issue here is that the releases should be
> numbered this way always so as to make a monotonic increasing sequence.
>
> Thus 2.063 should have been numbered 2.63.0.

Agreed, however we should also have a pre-release package for testing that is clearly marked as a pre-release, it can go on a separate web page to avoid any possibility of confusion.

The current release is showing as both 2.63.0 and 2.63 but I thought it was supposed to be 2.63.2 everywhere. This is very confusing.

--rt

On Tuesday, 9 July 2013 at 22:34:18 UTC, Rob T wrote:

>
> Agreed, however we should also have a pre-release package for testing that is clearly marked as a pre-release, it can go on a separate web page to avoid any possibility of confusion.
>
> The current release is showing as both 2.63.0 and 2.63 but I thought it was supposed to be 2.63.2 everywhere. This is very confusing.
>
> --rt

Running latest release shows this ...

DMD64 D Compiler v2.063

It should show the full release number.

--rt