View mode: basic / threaded / horizontal-split · Log in · Help
July 11, 2011
Re: dmd 1.069 and 2.054 release
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
July 11, 2011
Re: dmd 1.069 and 2.054 release
"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? :)
July 11, 2011
Re: dmd 1.069 and 2.054 release
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
July 11, 2011
Re: dmd 1.069 and 2.054 release
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
July 11, 2011
Re: dmd 1.069 and 2.054 release
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
July 11, 2011
Re: dmd 1.069 and 2.054 release
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
July 11, 2011
Re: dmd 1.069 and 2.054 release
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.
July 11, 2011
Re: dmd 1.069 and 2.054 release
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
July 11, 2011
Re: dmd 1.069 and 2.054 release
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__){...}
July 11, 2011
Re: dmd 1.069 and 2.054 release
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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home