On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution <
swift-evolution@swift.org> wrote:
> Alternatively, instead of replacing the current definition with an
> autoclosure version, we could leave the current version in place and add a
> version taking a function. This could be espec
On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users <
swift-us...@swift.org> wrote:
>
>
> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Yes, exactly. An Array is a struct wrapper for a reference type
>> representing storage
On Tue, Jul 25, 2017 at 4:44 AM, philohan95 via swift-evolution <
swift-evolution@swift.org> wrote:
> As you can see we had to use the properties twice (this would also be the
> case of `if let`) making the initializer twice as long as necessary and
> becomes a pain to implement when having more t
On Wed, Jun 28, 2017 at 8:49 PM, Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:
> As the screener of a non-zero number of radars resulting from unwrapped
> nils, I would certainly appreciate more use of guard let x = x else {
> fatalError(“explanation”) } and hope that !! would
On Mon, Apr 24, 2017 at 11:44 PM, David Waite via swift-evolution <
swift-evolution@swift.org> wrote:
> I still think this is a naming conflict more than anything else.
>
> The first expectation is that equatable and comparable provides strict
> equality and strict total ordering, and that those a
On Tue, Mar 21, 2017 at 10:51 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:
>
> The bug *does not affect what people use private for,* and so it *does not
> affect anything in real-world use.* It’s less “the Finder makes your files
> disappear on a regular basis” and mo
On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:
> A core team member (I'm blanking on who) has pointed out that, in the end,
> the only necessary access modifiers are public and not public (spelled
> "internal" in Swift).
>
>
> It is not clear
I also disagree with the proposal, and Drew's explanation is spot on.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
On Fri, Mar 10, 2017 at 6:08 AM, Rod Brown via swift-evolution <
swift-evolution@swift.org> wrote:
> Hi everyone. I found something odd that seems baked into how Cocoa Touch
> does protocols, but Swift cannot model it:
>
>
> @interface UIScrollView: UIView
>
> @property (weak, nonatomic) id deleg
On Wed, Mar 8, 2017 at 5:09 AM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:
> willSet and didSet have their own distinct scope; they execute
> independently, however a switch statement is effectively a single scope
> because of the ability to use fallthrough to visit later cas
On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:
> Here, a function call is an _intentional_ act. Writing a function not
> meant to be called is an _intentional_ act. It is strange that you would
> demand the compiler to stand between two of your o
On Thu, Feb 9, 2017 at 2:25 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:
> I wonder if an alternative to the original proposal might be to allow
> throw on the right hand side? So you could do:
>
> let y = x ?? throw myError
>
>
You can do this today:
extension Error {
On Sat, Jan 14, 2017 at 7:41 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:
> Oh... you mean that word(at:) itself would be linear, and thus
> algorithms that iterate the words linearly would be O(N^2)... yuck.
>
Couldn't you fix this by replacing `func word(at n: Int)
It's not as easy to type, but you can already use U+02B9 MODIFIER LETTER
PRIME for this purpose. Swift accepts this:
let x = 1
let xʹ = x + 1
let xʹʹ = xʹ + 1
let xʹʹʹ = xʹʹ + 1
On Wed, Jan 11, 2017 at 7:08 AM, Tuur Anton via swift-evolution <
swift-evolution@swift.org> wrote:
> I often have re
On Thu, Oct 20, 2016 at 9:29 AM, Jonathan S. Shapiro via swift-evolution <
swift-evolution@swift.org> wrote:
> Quick poll as a sanity check on a possible alternative for operators:
>
> If we admitted [:Sm:] and [:So:] and the traditional ASCII operator
> characters, would that cover the things tha
On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution <
swift-evolution@swift.org> wrote:
> In any case, I’d specifically hate to lose these:
>
> - approximate equality: ≈
> - set operations: ∩, ∪
> - set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋
> - set membership: ∌, ∋, ∈, ∉
> - logical operat
>> 1 | 2 ^ 3 // or this?
>
>
> No. Both of those are bitwise operations. They are often used together. They
> have a refined relative precedence in Swift that makes sense.
I have no idea what the relative precedence of those operators is in
Swift, C, or any other language, and thinking about it
Just to be clear, under your proposal, what does the following program
print? Can you make an argument in favor of your interpretation?
var x = 1
switch x {
case 1:
print("one")
x = 2
continue
case 2:
print("two")
default:
break
}
___
On Wed, Jul 6, 2016 at 2:57 PM, Tino Heth via swift-evolution
wrote:
> Can you talk about concrete examples? Because Objective-C had no variadic
> messages, it's natural that the feature isn't utilized in Cocoa
Objective-C has variadic messages. I'd be surprised if any seasoned
Objective-C devel
This is equivalent to the “Add an ifPresent function to Optional”
suggestion made back in March.
http://thread.gmane.org/gmane.comp.lang.swift.evolution/9173
Personally I'd prefer an `ifPresent` or `foreach` method to using
`map`, as `ifPresent` or `foreach` would make it clearer to the reader
th
On Mon, May 23, 2016 at 12:26 PM, David Sweeris via swift-evolution
wrote:
> Dunno about other IDEs, but Xcode's syntax highlighting can change the size,
> typeface (bold, italic, etc), and even the font. You can make instance
> variables show up as 24pt comic sans, if you want. You can’t do pol
We (you) shouldn't remove the NS prefixes from most of the classes in
the proposal. I agree with the reasons the other naysayers have given,
but I'll try to restate them in my own words.
Swift needs a better namespace/import system before these classes
should lose the NS prefix. Right now, you can
(-1)^sign * significand * radix^exponent
Significand is not like the other two, I guess, since nothing is raised to
it as a power...
On Fri, Apr 22, 2016 at 11:42 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:
>
> A floating point number is made up
> of three parts, a
>
>
> class UITableView {
> ...
> private func addRow(at indexPath: NSIndexPath) {
> ...
> cell.size.height = delegate?.tableView(self,
> heightForRowAtIndexPath: indexPath) ?? rowHeight
>
Check out the `testable` attribute:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/doc/uid/TP40014097-CH35-ID347
Lots of examples if you type `swift testable` into your favorite search
engine.
On Fri, Apr 1, 2016 at 4:
I would prefer the conditional statements to treat trailing closures
consistently, rather than allow this minor but inconsistent convenience. I
don't think this needs changing. I read the proposal and followed the list
discussion.
___
swift-evolution mail
My apologies if this was previously discussed. Was there ever a reason
given for not using operators for set combiners? That is, | & - ^ for
union, intersection, subtracting, and symmetricDifference, and |= &= -= ^=
for the mutating versions.
On Fri, Apr 1, 2016 at 12:14 AM, Douglas Gregor via swi
On Thu, Mar 31, 2016 at 10:56 AM, Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:
>
> protocol UIGestureRecognizerDelegate {
> var gestureRecognizerShouldBegin: ((gestureRecognizer:
> UIGestureRecognizer) -> Bool)? { get }
> }
>
UIGestureRecognizerDelegate has five meth
I think there will be confusion if these statements are inconsistent
regarding trailing closures.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Option 2i is the only one that neither discards nor makes up information,
and it doesn't seem like 2i would impose a significant burden on users.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-ev
Great idea, but why make it a free function instead of a Selector
initializer?
let sel1 = Selector(UIView.`insertSubview(_:at:)`)
let sel2 = Selector(UIView.`frame.get`)
Of course if there were such a thing as
GeneralizedFunctionNameLiteralConvertible, we could get a “free” conversion
to
>
> The braces being around the type specifier as well as function body rather
> bothers me. Surely it would be more consistent just to have the braces
> around the function body, and then the type specifier preceding this?
>
If you mean consistency between closures and function declarations,
woul
On Tue, Dec 22, 2015 at 12:33 AM, Zef Houssney via swift-evolution <
swift-evolution@swift.org> wrote:
> I agree with Stephen Celis that the best names for this (yet) are
> definitely `cases` and optionally `rawValues` if the cases are
> RawRepresentable.
>
That makes me want to say `for case in
When you access a static member of a type using the dot shortcut, Swift
evaluates the expression immediately.
Are you proposing that when you access a member of an instance, Swift
generate a closure?
Or are you proposing that Swift generate a closure or not depending on how
the expression's value
34 matches
Mail list logo
