Re: [swift-evolution] Pitch: Improved Swift pointers

I agree with most of this proposal. Removing the subscript bugs me, but pointer arithmetic currently takes the stride of the type into account, so I don’t necessarily have a problem with that. I would really appreciate Unsafe*BufferPointer.allocate(count:), and I definitely think the sized deal

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1 for using :: It’s got precedence in many other languages (C++, Java 8+, Kotlin) to reference static methods, and it’s sufficiently different enough from `.` to avoid confusing people. While I personally resist letting C++ influence Swift syntactically, this makes a lot of sense to me. — Ha

[swift-evolution] SwiftPM C++ Support

Hi swift-evolution! Robert Widmann and I have been working on a Swift wrapper for LLVM (https://github.com/harlanhaskins/LLVMSwift ) and we’re lamenting the lack of C++ support in SwiftPM. Ideally, we’d be able to write C++ files that expose C APIs f

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

>> >> On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution wrote: >>> Swift developers frequently use string interpolation as a convenient, >>> concise syntax for interweaving variable values with strings. The >>> interpolation machinery, h

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

plicit casting or using the debugDescription. > > I’m not sure we really need an evolution proposal for that. > > As for the more general topic of trickiness around optional injection into > unconstrained generics: Yes, we should review that at some point as well. I &g

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

is used as an Any. I disagree that > this should be an error, but it seems reasonable to warn (if we don't already > thanks to the 'Any' warning). > > -Joe > >> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution >> wrote: >> >&g

[swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

Hey all, Julio Carrettoni, Robert Widmann, and I have been working on a proposal to mitigate something that's burned us all since Swift 1. We'd love some feedback! It's available here: https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd I've posted the current draft below.

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

I’ve also seen unsafeAddressOf(_:) used when interfacing with C function pointers when the lifetime of an object is guaranteed. Many C APIs vend an API like: void perform_action(void (*callback)(void *data), void *initial_data); For which it is expected to use unsafeAddressOf on a class instanc

Re: [swift-evolution] Objective-C’s @compatibility_alias => Swift’s typealias?

+1. Robert and I are toying with an implementation right now; it’s really straightforward. — Harlan > On Jun 30, 2016, at 3:16 PM, Ayaka Nonaka via swift-evolution > wrote: > > Hi Swift community, > > I was wondering if bridging Objective-C’s @compatibility_alias to Swift’s > typealias is s

Re: [swift-evolution] [Pitch] #warning

Based on the feedback from this list, I’ve submitted a revised proposal as PR #353. https://github.com/apple/swift-evolution/pull/353 Thanks, Harlan > On Jun 1, 2016, at 9:25 PM, Ben Langmuir via swift-evolution > wrote: > >> >> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution

Re: [swift-evolution] [Pitch] #warning

FWIW, I'm also in favor of adding #error to the language. It would be good to express invariants that the compiler can't know about, like mutually exclusive build config options that affect code downstream. I'm definitely seeing how #warning might conflict with the goals of Swift's warnings. I

Re: [swift-evolution] [Pitch] #warning

o add their own warnings which can then just > be ignored just encourages the very bad habit of ignoring warnings in > general. Perhaps this could be something for libIDE, rather than the core > language? > > > > Jon Shier > >> On May 28, 2016, at 7:58 PM, Harl

[swift-evolution] [Pitch] #warning

Hey everyone, I’m working on a draft for #warning in Swift. I’ve implemented the draft as it stands, and it’s pretty nice to work with. I’ve pasted it below, and I’d love some feedback! Thanks! — Harlan Haskins #warning Proposal: SE-

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

You could always do your control flow with goto’s anyway… func foo() { var i = 0 func goto(_ label: String = "entry") { switch label { case "entry": print("beginning loop…") goto("cond") case "cond": goto(i < 10 ? "body" : "end") case "body": i += 1

Re: [swift-evolution] Limit checking syntax

I’ve found that .contains works well for all my uses. (0..<100).contains(x) > On Apr 7, 2016, at 1:17 PM, Maury Markowitz via swift-evolution > wrote: > > I originally posted this in swift-users, and it garnered some level of > positive reaction, so I thought I would try it again here. > > W

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

I still absolutely think the best proposal for this is to add a Fraction type to the standard library with easy conversions to and from all the numeric types. Your precision is only limited by the size of IntMax, and you can do whatever operations you want without losing precision. There’s a gre

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

Since we’re allowing keywords as argument names, shouldn’t this: func foo(let i: Int) be allowed, such that it’ll be called as this: foo(let: 3) — Harlan > On Mar 17, 2016, at 11:08 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Mar 17, 2016, at 1:27 AM, Nicholas Maccharoli via

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

I agree — my reasoning was that it’s more like the current iOS availability statement. I wonder if the iOS availability statement could use some work too? It’s kinda weird and magical ("why do I have to type that *?") > On Dec 18, 2015, at 3:56 PM, David Farler wrote: > > I had considered thi

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

How about #if swift(2, 2, *) #endif ? > On Dec 18, 2015, at 3:32 PM, David Farler via swift-evolution > wrote: > >> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner wrote: >> >> >>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution >>> wrote: >>> >>> Sounds like it