On Monday 11 July 2011 15:31:11 Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1523.1310360242.14074.digitalmars-d-announce@puremagic.com...
> 
> > *Sigh* I really need to kill the shortcut in my e-mail client for
> > sending
> > messages. I was about to say that an implementation of
> > http://d.puremagic.com/issues/show_bug.cgi?id=5481  _is_ essentially
> > what
> > we
> > need but that your example seems to show a lack of understanding of the
> > feature (particularly with regards to "scheduled for deprecation" rather
> > than
> > full deprecation).
> 
> Well, that is why I asked.  Yes, what I'm proposing is not exactly what was in the bug report.
> 
> The way it seems to be done, removing a feature has three stages:
> 1. schedule for deprecation
> 2. mark as deprecated
> 3. remove it
> 
> The point of stage 1 seems to be to warn the programmer that some time in the future they're going to need -d to compile their code.  I'm really not convinced that this message should always be displayed, as most of the time it's useless noise.  It does however make sense to print it out when compiling with -v or generate a warning when compiled with -w (or -wi).
> 
> Then again, maybe 'scheduled for deprecation' is something that should be a lower level than warning. (If D had warning levels)  In this case it should still only print with -v or -w.

A message needs to be printed in stage 1. Whether it should always be printed is debatable. But without the message, unless the programmer is re-reading the documentation, they won't see that something has been scheduled for deprecation. On some level, the programmer _should_ be bugged about it, because they need to change their code, but on the other hand, it's scheduled for deprecation rather than deprecated precisely so that the programmer has time to change their code before the item in question is deprecated, so always bugging about it doesn't really make sense either. So, making it so that it only prints with -v or -w is probably fine. But regardless, the whole point is to alert the programmer so that they have the chance to change their code before they need to start compiling with -d. So, the message needs to be there, but I'm not sure that I really care that much about whether it always prints or not. Having it always print with -w, -wi, or -v but otherwise not print is probably fine.

> > With that implemented, it would fix the problem for functions, but I'm
> > not sure
> > that it would fix the problem for modules. That would depend on how it
> > was implemented. As it stands, if you deprecate an entire module, you
> > end up doing
> > something like
> > 
> > deprecated:
> > 
> > at the top of the module, which is then going to complain about each
> > symbol in
> > the model individually when you use it. Ideally, you could make it
> > complain
> > about the module when it's imported (and then maybe the specific
> > functions on
> > top of that), and that syntax doesn't really give you that. It just
> > makes
> > it
> > complain about the symbols when you use them. But that can work too.
> 
> Ok, would this be fixed by allowing:
> deprecated module mymodule;
> and the rest of it?

I think that it's all been covered. Stage 1 needs an appropriate message and a way to put that message on specific symbols (and possibly modules). Stage 2 currently works as-is but would be better with a message. And, of course, stage 3 works quite well without any features at all.

So, overall I think that that covers it. The exact details of how it interacts with compiler flags is up for some debate, and I'm not sure that I care a whole lot about how that's dealt with except that the messages for stage 1 need to be seen, so they need to be displayed when a reasonable set of compiler flags is used. Otherwise, the deprecation will come to surprise to people and cause them even more problems.

- Jonathan M Davis

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
news:mailman.1524.1310363419.14074.digitalmars-d-announce@puremagic.com...
[snip]
Yeah ok, I think we're more or less on the same page now.

Looking at the implementation of deprecated, I think in order to support messages it's going to need to become a pragma rather than a storage class. (at least internally)

Maybe we should deprecate deprecated? :)

On Monday 11 July 2011 17:29:07 Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
> news:mailman.1524.1310363419.14074.digitalmars-d-announce@puremagic.com...
> [snip]
> Yeah ok, I think we're more or less on the same page now.
> 
> Looking at the implementation of deprecated, I think in order to support messages it's going to need to become a pragma rather than a storage class. (at least internally)
> 
> Maybe we should deprecate deprecated? :)

LOL. Well, from the programmer's point of view, I don't think that it really matters how deprecated is implemented internally. It just needs to work. However, regardless of its being able to take a message or type of deprecation, the current behavior of deprecated needs to stay intact. Its new abilities need to be in addition to how it currently works rather than replacing them.

- Jonathan M Davis

On 2011-07-11 05:07, Walter Bright wrote:
> Continuing the trend, more people contributed to this release than any
> other!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.069.zip
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.054.zip

That was no short list, impressive.

-- 
/Jacob Carlborg

On Monday 11 July 2011 10:01:26 Jacob Carlborg wrote:
> On 2011-07-11 05:07, Walter Bright wrote:
> > Continuing the trend, more people contributed to this release than any other!
> > 
> > http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.069.zip
> > 
> > http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.054.zip
> 
> That was no short list, impressive.

It definitely is impressive. Probably the longest list ever. I would point out however, that this line shouldn't be in the changelog:

* Add warning about calling pure nothrow functions and ignoring the result

That change was reverted after it was discovered that it caused too many problems.

- Jonathan M Davis

On Monday 11 July 2011 01:11:09 Jonathan M Davis wrote:
> On Monday 11 July 2011 10:01:26 Jacob Carlborg wrote:
> > On 2011-07-11 05:07, Walter Bright wrote:
> > > Continuing the trend, more people contributed to this release than
> > > any
> > > other!
> > > 
> > > http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.069.zip
> > > 
> > > http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.054.zip
> > 
> > That was no short list, impressive.
> 
> It definitely is impressive. Probably the longest list ever. I would point out however, that this line shouldn't be in the changelog:
> 
> * Add warning about calling pure nothrow functions and ignoring the result
> 
> That change was reverted after it was discovered that it caused too many problems.

Oh, and this line should be removed too:

* Added inference for purity and safety

It's basically listed twice, since there's also this line (which is more accurate):

* Automatic inference for @safe, pure, nothrow

- Jonathan M Davis

On 11.07.2011 05:07, Walter Bright wrote:
> Continuing the trend, more people contributed to this release than any
> other!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.069.zip
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.054.zip

Nice release list.


"Added std.array.uninitializedArray and std.array.minimallyInitializedArray"

The online documentation of std.array doesn't seem to be updated. The above isn't present there.

On Monday 11 July 2011 11:00:15 Stephan wrote:
> On 11.07.2011 05:07, Walter Bright wrote:
> > Continuing the trend, more people contributed to this release than any other!
> > 
> > http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.069.zip
> > 
> > http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.054.zip
> 
> Nice release list.
> 
> 
> "Added std.array.uninitializedArray and std.array.minimallyInitializedArray"
> 
> The online documentation of std.array doesn't seem to be updated. The above isn't present there.

Give it some time. A new release and the updating of the online documentation aren't automatically linked. Walter is the one putting up the new release, I believe that Andrei is the one who has to update the site. Walter put up the release about 6 hours ago. There's a decent chance that Andrei isn't even aware that the release has been done yet. The site will be probably be updated within the next 24 hours. But regardless, the fact remains that the site update and the release itself aren't done by the same person, so the site update is likely to be somewhat delayed. The docs in the zip file should be properly up-to-date.

- Jonathan M Davis

On 11.07.2011 05:07, Walter Bright wrote:
> Continuing the trend, more people contributed to this release than any
> other!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.069.zip
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.054.zip

I like this one:
"Added -property switch"

But since phobos does not even build with it (in win32) it is pretty much useless:

phobos\std\file.d(228): Error: not a property GetLastError:

version(Windows) this(in char[] name,
                          uint errno = GetLastError,
                          string file = __FILE__,
                          size_t line = __LINE__){...}

On 7/11/2011 2:21 AM, Stephan wrote:
> But since phobos does not even build with it (in win32) it is pretty much useless:

Right, that's why it was not made the default. It is there for people to experiment with.