On Tue, May 9, 2017 at 12:34 AM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:
> On Fri, May 5, 2017 at 4:00 PM Xiaodi Wu wrote:
>
>> The reason I suggest this is that the most consistent boundary with the
>> rest of Swift is the module. I don't doubt that some may wish to
On Fri, May 5, 2017 at 4:00 PM Xiaodi Wu wrote:
> The reason I suggest this is that the most consistent boundary with the
> rest of Swift is the module. I don't doubt that some may wish to deprecate
> features even for some subset of internal users, but it seems plainly
> obvious to me that the m
On Sat, May 6, 2017 at 9:21 PM Brent Royal-Gordon
wrote:
> [Re-sending with minor edits since this didn't initially go to the list.]
>
> > On May 5, 2017, at 3:25 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hi Tony, this is called out in the proposal :) In
[Re-sending with minor edits since this didn't initially go to the list.]
> On May 5, 2017, at 3:25 PM, Tony Allevato via swift-evolution
> wrote:
>
> Hi Tony, this is called out in the proposal :) In addition to the fact that
> it requires writing boilerplate code manually and updating all re
I understand the reasoning and am in favor of it for those reasons, but
I will note that I use deprecations extremely frequently while
refactoring, and this would defeat that use case. As I have a few larger
projects with long compile times, losing that functionality would be
disappointing.
Sincere
One potential pitfall of auto-disabling the warning for various scopes,
especially the file one, is that one can by mistake add a new unintended
reference. Even though it require extra change when deprecating, should there
be instead a way to tag the "authorized" use.
@useDeprecated(self.phoneN
The problem happened on deprecated public protocols in ReactiveSwift. Since
conformance cannot be stripped until it is inaccessible, we have a bunch of
deprecation warnings on conformance clauses, scattered in the codebase. Having
this on a file basis is not enough in our cases, while for sure n
The reason I suggest this is that the most consistent boundary with the
rest of Swift is the module. I don't doubt that some may wish to deprecate
features even for some subset of internal users, but it seems plainly
obvious to me that the more common scenario will be deprecating for public
consump
On Fri, May 5, 2017 at 3:20 PM Tony Arnold wrote:
> Hi Tony,
>
> > On 6 May 2017, at 04:12, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > These warnings are emitted for any reference to a deprecated entity,
> including those in the same file. In some cases, howev
Hi Tony,
> On 6 May 2017, at 04:12, Tony Allevato via swift-evolution
> wrote:
>
> These warnings are emitted for any reference to a deprecated entity,
> including those in the same file. In some cases, however, it may be necessary
> and correct to continue referring to the deprecated entity
I'm inclined to agree. I'm not opposed outright to that degree of
configurability but at the same time I wonder if the complexity is
needed—it feels like it's getting close to the "fine-tuned auditing" that I
argued against during the discussions about access control.
It could also be done additiv
> On May 5, 2017, at 1:34 PM, Xiaodi Wu wrote:
>
> Why guess as to which of these is appropriate? Couldn't you support the
> current and all variants of this behavior by allowing access modifiers on
> 'deprecated'?
>
> * public deprecated: warning when used from a different module, behaves as
Why guess as to which of these is appropriate? Couldn't you support the
current and all variants of this behavior by allowing access modifiers on
'deprecated'?
* public deprecated: warning when used from a different module, behaves as
though there's a public deprecated pass-through
* internal dep
On Fri, May 5, 2017 at 11:37 AM BJ Homer wrote:
> I’ve run into this problem as well, when dealing with legacy file formats
> (similar to the example in the proposal), and I agree it would be nice to
> be able to address it. We’ve got a few “permanent” warnings in our code
> base right now due to
I’ve run into this problem as well, when dealing with legacy file formats
(similar to the example in the proposal), and I agree it would be nice to be
able to address it. We’ve got a few “permanent” warnings in our code base right
now due to this. I’m not sure whether the deprecation should be d
Hey Swift Evolvers,
I'd like to propose a change that would suppress deprecation warnings when
the reference to the deprecated declaration is in the same file as that
declaration.
This personally affects one of my projects (Swift protocol buffers) because
.proto files allow declarations to be dec
16 matches
Mail list logo
