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 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
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 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 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 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 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 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
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
(-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
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
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
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
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
}
___
>> 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
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
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
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 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)
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
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
>
> 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
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
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
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
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
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
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
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:
>
>
> class UITableView {
> ...
> private func addRow(at indexPath: NSIndexPath) {
> ...
> cell.size.height = delegate?.tableView(self,
> heightForRowAtIndexPath: indexPath) ?? rowHeight
>
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 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 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, 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
34 matches
Mail list logo