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