[Issue 199] Label causes scope to collapse into parent

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=199



--- Comment #33 from monarchdodra at gmail.com 2013-06-07 02:08:53 PDT ---
(In reply to comment #32)
> (In reply to comment #31)
> > >> The (imo correct) path is that the NoScopeStatment should still 
> > >> provide no scope, but emit a deprecated message if anything 
> > >> declared in the scope is used.
> > 
> > If you're going to go as far as that, why not emit a deprecation message if any
> > declarations appear in it at all?
> 
> That sounds easier to implement, and IMO is a bit better than deprecating
> having a non-empty block after a label. We would also need to deprecate having
> scope() statements in a labelled block. Bug 827 would also need a solution.

Deprecating having a block after a label is wrong, and so is having a scope
statement inside a labeled block. These are valid use cases of code, and both
valid according to spec, old and new. Just because something is changing (more
so, arguably being fixed), doesn't mean all previous usage of the code was
wrong.

> comment #30:
> > I understand your position, but deprecation really implies that something WILL
> > be removed, and usage NEEDS to stop. Having something permanently deprecated is
> > not tenable: there is a compile mode that makes deprecated calls errors, and
> > here, it is not an error.
> 
> If a user has chosen to enable deprecation errors, that is their problem IMO.
> By default the code would not break.

The idea of deprecation is that something is removed, because that specific
usage has been decided un-worthy, and usage should stop. This usually comes
with an different/superior alternative. The error-on-deprecate are for users
that want to keep their code up to date with the latest standard.

This is not what we are doing at all. We changed a behavior, but there is
nothing wrong with the code, and more importantly, there is no alternative to
migrate to.

> Note: GTK2 kept its deprecated symbols until GTK3, rather than scheduling
> removal at a certain date.

Yes, but they *were* scheduled for deprecation, and probably for a good reason.
There is no good reason for a user to not use a labeled scope.

> Anyway, a limited period of deprecation rather than just changing behaviour
> might be a good compromise. Perhaps 2 years?

I agree with Stewart, this all out of proportion. For starters, cases where
code would actually break are minimal, and contrived. Not only that, but labels
aren't something widely used anyways. In particular, I'd *highly* doubt that
*anybody* actually explicitly relied on this behavior (or even knew about
it...).

If anything, the only changes in behavior I would expect are:
a) Wrong code stops compiling (a good thing)
b) Symbols weren't used anyways, no change
c) User *expected* the end of the block to call a destroyer. The silently
failing code would now be fixed.

I really think the best solution here is just to fix the damn thing and move
on.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------