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
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
Still confused about what is removed and what is confusing, all example use
identical label and variable name and construct which seems atypical. I think
that a better shuffling example (at least I think it's shuffling) would be a
date tuple. All expect such tuple to contains a day, a month and
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
There is nothing consistent in the following example:
let (x: a, y: b) = (x: 0, y: 1)
Labels are not simple descriptors, they signal that the assignment for the RHS
will happen to some constant associated with the label. The assignment
direction is from right-to-left! Labeled tuple destructuring
I have one concern and one general comment.
General comment: there's a switch to turn off overflow checks for performance
reasons. It seems to me that this check is going to be much more expensive than
an overflow check, and it's certainly not much more likely to trigger in a
release build afte
> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution
> wrote:
>
> I have one concern and one general comment.
>
> General comment: there's a switch to turn off overflow checks for performance
> reasons. It seems to me that this check is going to be much more expensive
> than an o
This is exactly the syntax for enum case patterns in switch statements.
You're asserting that it's inconsistent with something, but I don't see any
inconsistency. I don't understand what you mean by right-to-left assignment
or inout variables.
Robert's example is confusing because the variables ar
I guess that the example doesn't make a lot of sense outside of collections,
and the proposal already says that swap needs to be implemented on collections,
but consider the Fisher-Yates shuffle:
-- To shuffle an array a of n elements (indices 0..n-1):
for i from n−1 downto 1 do
j ← random i
As a number of recent threads have shown, typed throws and error handling is a
complicated topic with a lot of implications.
However in the mean time we could potentially address one of the pain points
people give for wanting typed throws - exhaustive catch statements.
For functions that you co
_If_ this is something that's important, then the ! should follow 'catch'
and not 'try'.
The keyword 'try!' already means something, and it's not that. People may
already mix try! and try in a do block and the behavior cannot be changed
for source compatibility.
On Sat, May 6, 2017 at 15:16 Simon
> On May 5, 2017, at 11:06 PM, Xiaodi Wu wrote:
>
> The identifier after a colon is *never* a type in any pattern matching, and
> there's no need of which I'm aware to support type annotations in pattern
> matching. We put colons after labels, and the current syntax is perfectly
> consistent h
I actually half agree with you that this behaviour would be conceptually
related to the do-catch block (although not a specific catch statement). So
maybe alternatively the shorthand for this-
do {
try throwingFunction()
} catch MyError.TheError {
// do something
} ca
To which human would it be misleading?
To the writer? No, because the compiler will warn you right away. By the
time you're done with writing the first line, it'll warn you that Int and
Double are unused variables. And if you try to use x and y, you get an
error.
To the reader? Only if the writer
> On May 4, 2017, at 3:01 PM, Xiaodi Wu via swift-evolution
> wrote:
>
> Hmm, I can see the appeal of automatically deriving Equatable and Hashable
> conformance, but I'd like that to be opt-in. That is, types should declare
> that they are Equatable or Hashable to begin with. It wouldn't hav
On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution
wrote:
>
>
>
> Can the opt-in conformance be declared in an extension? If so, can the
> extension be in a different module than the original declaration? If so, do
> you intend any restrictions, such as requiring all members of
> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
>
>
>> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> Concern: `swap` is quoted a lot for a method that would break und
[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
18 matches
Mail list logo
