July 11, 2011
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1522.1310360091.14074.digitalmars-d-announce@puremagic.com...
> On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
>>
>> Would the following cover all the common use cases? (Phobos seems to be
>> the
>> biggest user of deprecated so far)
>>
>> deprecated("message") int a;
>> deprecated("message", warn) int b;
>>
>> With deprecated(warn) messages only being displayed with warnings enabled.
>
> No. That's not quite right. If something is actually deprecated, -d is
> required to compile using it. Being able to have a message with it - e.g.
> deprecated("message") - would be very useful, because it could tell you
> what
> you're supposed to use instead (or that nothing is replacing it if that's
> the
> case). Error vs warning has nothing to do with it. Now, it could be that
> compiling with -w would result in the message being printed even if you
> compiled with -d, but that's debatable.
>
> In the case of something which is scheduled for deprecation, the code
> should
> compile regardless. A message would print if that symbol were used, but
> beyond
> that, nothing happens. That _could_ be made so that it only prints when
> you
> compile with -w, and if it's classified as a warning, then that would make
> sense, except that it shouldn't stop compilation even if compiling
> with -w, so
> it can't really follow what warnings normally do with -w. So, how it
> should
> function with regards to -w is debatable.
>

Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.


July 11, 2011
== Quote from Walter Bright (newshound2@digitalmars.com)'s article
> On 7/11/2011 7:04 AM, dsimcha wrote:
> > Great release!  I noticed that auto ref function parameters are now implemented, but only for template functions.  Is there a reason for this limitation?  Example:
> >
> > Works:
> >
> > void foo()(auto ref int num) {
> >      num++;
> > }
> >
> > Doesn't:
> >
> > void foo(auto ref int num) {
> >      num++;
> > }
> auto ref changes the code generated for the function body, so it must be a template.

So are there multiple instantiations depending on rvalue vs. not rvalue?
July 11, 2011
On 7/11/2011 10:02 AM, dsimcha wrote:
> So are there multiple instantiations depending on rvalue vs. not rvalue?

Yes, it has to be that way. It's the difference between passing T* and T.
July 11, 2011
On 2011-07-11 09:34, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1522.1310360091.14074.digitalmars-d-announce@puremagic.com...
> 
> > On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
> >> Would the following cover all the common use cases? (Phobos seems to be
> >> the
> >> biggest user of deprecated so far)
> >> 
> >> deprecated("message") int a;
> >> deprecated("message", warn) int b;
> >> 
> >> With deprecated(warn) messages only being displayed with warnings
> >> enabled.
> > 
> > No. That's not quite right. If something is actually deprecated, -d is
> > required to compile using it. Being able to have a message with it - e.g.
> > deprecated("message") - would be very useful, because it could tell you
> > what
> > you're supposed to use instead (or that nothing is replacing it if that's
> > the
> > case). Error vs warning has nothing to do with it. Now, it could be that
> > compiling with -w would result in the message being printed even if you
> > compiled with -d, but that's debatable.
> > 
> > In the case of something which is scheduled for deprecation, the code
> > should
> > compile regardless. A message would print if that symbol were used, but
> > beyond
> > that, nothing happens. That _could_ be made so that it only prints when
> > you
> > compile with -w, and if it's classified as a warning, then that would
> > make sense, except that it shouldn't stop compilation even if compiling
> > with -w, so
> > it can't really follow what warnings normally do with -w. So, how it
> > should
> > function with regards to -w is debatable.
> 
> Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.

True. But when we're dealing with messages for something which is scheduled for deprecation, they're _not_ warnings. They're messages. They should never cause compilation to fail. What the best way to handle when they print or not is debatable, but they should never cause compilation to fail. So, even if they were printed because -w was used, they still shouldn't be errors. Personally, I'd probably just have them always print (and possibly include a separate flag for turning them off), but even if -w were used for enabling them, they shouldn't be errors. They're just messages. It's stuff that's actually deprecated that affects compilation.

- Jonathan M Davis
July 11, 2011
== Quote from Walter Bright (newshound2@digitalmars.com)'s article
> On 7/11/2011 10:02 AM, dsimcha wrote:
> > So are there multiple instantiations depending on rvalue vs. not rvalue?
> Yes, it has to be that way. It's the difference between passing T* and T.

Couldn't you just make the calling convention for auto ref functions be to always pass a T* and create a hidden temporary at the call site if passing an rvalue?
July 11, 2011
On 7/11/2011 12:16 PM, dsimcha wrote:
> Couldn't you just make the calling convention for auto ref functions be to always
> pass a T* and create a hidden temporary at the call site if passing an rvalue?

That can produce a lot of hidden overhead, pretty much wrecking the advantages of pass by value.
July 11, 2011
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1536.1310408114.14074.digitalmars-d-announce@puremagic.com...
> On 2011-07-11 09:34, Nick Sabalausky wrote:
>> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1522.1310360091.14074.digitalmars-d-announce@puremagic.com...
>>
>> > On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
>> >> Would the following cover all the common use cases? (Phobos seems to
>> >> be
>> >> the
>> >> biggest user of deprecated so far)
>> >>
>> >> deprecated("message") int a;
>> >> deprecated("message", warn) int b;
>> >>
>> >> With deprecated(warn) messages only being displayed with warnings
>> >> enabled.
>> >
>> > No. That's not quite right. If something is actually deprecated, -d is
>> > required to compile using it. Being able to have a message with it -
>> > e.g.
>> > deprecated("message") - would be very useful, because it could tell you
>> > what
>> > you're supposed to use instead (or that nothing is replacing it if
>> > that's
>> > the
>> > case). Error vs warning has nothing to do with it. Now, it could be
>> > that
>> > compiling with -w would result in the message being printed even if you
>> > compiled with -d, but that's debatable.
>> >
>> > In the case of something which is scheduled for deprecation, the code
>> > should
>> > compile regardless. A message would print if that symbol were used, but
>> > beyond
>> > that, nothing happens. That _could_ be made so that it only prints when
>> > you
>> > compile with -w, and if it's classified as a warning, then that would
>> > make sense, except that it shouldn't stop compilation even if compiling
>> > with -w, so
>> > it can't really follow what warnings normally do with -w. So, how it
>> > should
>> > function with regards to -w is debatable.
>>
>> Despite the confusing non-standard descriptions in --help, -w is the
>> "Treat
>> warnings as errors" setting, so it *should* stop compilation - that's the
>> whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.
>
> True. But when we're dealing with messages for something which is
> scheduled
> for deprecation, they're _not_ warnings. They're messages. They should
> never
> cause compilation to fail. What the best way to handle when they print or
> not
> is debatable, but they should never cause compilation to fail. So, even if
> they were printed because -w was used, they still shouldn't be errors.
> Personally, I'd probably just have them always print (and possibly include
> a
> separate flag for turning them off), but even if -w were used for enabling
> them, they shouldn't be errors. They're just messages. It's stuff that's
> actually deprecated that affects compilation.
>

Not that I feel strongly about it, but just like "scheduled for deprication", actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a "warnings as errors" setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for "warnings as errors" settings anyway.)

To be clear, if we did have some "deprecated(scheduled)" feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that "scheduled for deprication" doesn't essentially amount to a warning.


July 11, 2011
On 2011-07-11 13:09, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1536.1310408114.14074.digitalmars-d-announce@puremagic.com...
> 
> > On 2011-07-11 09:34, Nick Sabalausky wrote:
> >> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1522.1310360091.14074.digitalmars-d-announce@puremagic.com. ..
> >> 
> >> > On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
> >> >> Would the following cover all the common use cases? (Phobos seems to
> >> >> be
> >> >> the
> >> >> biggest user of deprecated so far)
> >> >> 
> >> >> deprecated("message") int a;
> >> >> deprecated("message", warn) int b;
> >> >> 
> >> >> With deprecated(warn) messages only being displayed with warnings
> >> >> enabled.
> >> > 
> >> > No. That's not quite right. If something is actually deprecated, -d is
> >> > required to compile using it. Being able to have a message with it -
> >> > e.g.
> >> > deprecated("message") - would be very useful, because it could tell
> >> > you what
> >> > you're supposed to use instead (or that nothing is replacing it if
> >> > that's
> >> > the
> >> > case). Error vs warning has nothing to do with it. Now, it could be
> >> > that
> >> > compiling with -w would result in the message being printed even if
> >> > you compiled with -d, but that's debatable.
> >> > 
> >> > In the case of something which is scheduled for deprecation, the code
> >> > should
> >> > compile regardless. A message would print if that symbol were used,
> >> > but beyond
> >> > that, nothing happens. That _could_ be made so that it only prints
> >> > when you
> >> > compile with -w, and if it's classified as a warning, then that would
> >> > make sense, except that it shouldn't stop compilation even if
> >> > compiling with -w, so
> >> > it can't really follow what warnings normally do with -w. So, how it
> >> > should
> >> > function with regards to -w is debatable.
> >> 
> >> Despite the confusing non-standard descriptions in --help, -w is the
> >> "Treat
> >> warnings as errors" setting, so it *should* stop compilation - that's
> >> the whole point of -w. The proper "Turn warnings on" setting is -wi,
> >> not -w.
> > 
> > True. But when we're dealing with messages for something which is
> > scheduled
> > for deprecation, they're _not_ warnings. They're messages. They should
> > never
> > cause compilation to fail. What the best way to handle when they print or
> > not
> > is debatable, but they should never cause compilation to fail. So, even
> > if they were printed because -w was used, they still shouldn't be
> > errors. Personally, I'd probably just have them always print (and
> > possibly include a
> > separate flag for turning them off), but even if -w were used for
> > enabling them, they shouldn't be errors. They're just messages. It's
> > stuff that's actually deprecated that affects compilation.
> 
> Not that I feel strongly about it, but just like "scheduled for deprication", actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a "warnings as errors" setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for "warnings as errors" settings anyway.)
> 
> To be clear, if we did have some "deprecated(scheduled)" feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that "scheduled for deprication" doesn't essentially amount to a warning.

Hmm. The main problem with making the scheduled for deprecation messages being treated as errors with -w is that if you build with -w (as a lot of people do), it breaks your code. And the point of the message is to warn you that your code is _going_ to break and to _avoid_ causing immediate breakage.

So, I don't know what the best way to handle to scheduled for deprecation messages is, but they really shouldn't cause code to not compile or force you to use a specific flag to make your code compile. Otherwise, we might as well just fully deprecate them from the get-go.

The simplest way is to just always print the messages until you fix your code, but that could be annoying. So, I don't know. But scheduled for deprecation messages must not break code.

- Jonathan M Davis
July 11, 2011
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1539.1310416341.14074.digitalmars-d-announce@puremagic.com...
> On 2011-07-11 13:09, Nick Sabalausky wrote:
>>
>> Not that I feel strongly about it, but just like "scheduled for deprication", actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a "warnings as errors" setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for "warnings as errors" settings anyway.)
>>
>> To be clear, if we did have some "deprecated(scheduled)" feature and it
>> was
>> non-fatal even with -w, I wouldn't personally have a huge problem with it
>> (I never use -w anyway, just -wi). I just don't think it's so clear-cut
>> that "scheduled for deprication" doesn't essentially amount to a warning.
>
> Hmm. The main problem with making the scheduled for deprecation messages
> being
> treated as errors with -w is that if you build with -w (as a lot of people
> do), it breaks your code. And the point of the message is to warn you that
> your code is _going_ to break and to _avoid_ causing immediate breakage.
>

If someone doesn't want warning conditions to break their code, they should be using -wi, not -w.



July 11, 2011
On 2011-07-11 13:50, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1539.1310416341.14074.digitalmars-d-announce@puremagic.com...
> 
> > On 2011-07-11 13:09, Nick Sabalausky wrote:
> >> Not that I feel strongly about it, but just like "scheduled for deprication", actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a "warnings as errors" setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for "warnings as errors" settings anyway.)
> >> 
> >> To be clear, if we did have some "deprecated(scheduled)" feature and it
> >> was
> >> non-fatal even with -w, I wouldn't personally have a huge problem with
> >> it (I never use -w anyway, just -wi). I just don't think it's so
> >> clear-cut that "scheduled for deprication" doesn't essentially amount
> >> to a warning.
> > 
> > Hmm. The main problem with making the scheduled for deprecation messages
> > being
> > treated as errors with -w is that if you build with -w (as a lot of
> > people do), it breaks your code. And the point of the message is to warn
> > you that your code is _going_ to break and to _avoid_ causing immediate
> > breakage.
> 
> If someone doesn't want warning conditions to break their code, they should be using -wi, not -w.

Yes. But the problem is that the "scheduled for deprecation" messages are not supposed to _ever_ break code. And since warnings aren't normally added very often, compiling with -w shouldn't cause your code to suddenly break. Granted, dmd is still unstable enough that such changes do occur, but once it's fully stable, it wouldn't happen very often. But anyone can schedule something for deprecation in any library, and the whole point of _scheduling_ the deprecation instead of just deprecating it is to avoid breaking code. So, it's unacceptable for scheduling something for deprecation to be an error with -w. It's informational only. Warnings are _not_ only informational. They're telling you that there's actually something wrong with your code. It's just not wrong enough to be against the language spec and therefore always be an error. Scheduling something for deprecation is indicating that the symbol in question will be deprecated in the future and that you should change it before that happens. Your code is still fine, and it should still compile.

Bottom line. Marking something as "scheduled for deprecation" should _never_ break code no matter what flags you use to compile your code. Otherwise, there's no point to it, and we'd just be deprecating stuff immediately.

- Jonathan M Davis