Re: [swift-evolution] Ad hoc enums / options

How about this: Going back to Erica’s original example: func scaleAndCropImage( image: UIImage, toSize size: CGSize, operation: (.Fit | .Fill) = .Fit ) -> UIImage { And noting that we are already allowed to declare an enum inside the function, compiler can generate an enum

Re: [swift-evolution] Ad hoc enums / options

thinking about complexity > > On Jun 4, 2016, at 4:58 PM, Hooman Mehr via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> How about this: >> >> >> Going back to Erica’s original example: >> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Exactly what I feel about this. I am prepared to go as far as disallowing: let x = optionalX, y = optionalY syntax to free up comma for use instead of semicolon. Then the above becomes: let x = optionalX, let y = optionalY In this case we will keep the comma at the end of the line as well.

Re: [swift-evolution] Ad hoc enums / options

If we go back to your original example: func scaleAndCropImage( image: UIImage, toSize size: CGSize, fitImage: Bool = true ) -> UIImage { There is a different type of sugar that I would like to have: Having label stand for `true` when we have a defaulted boolean flag, whose

Re: [swift-evolution] Ad hoc enums / options

Correction/ Clarification. My assumption. The signature I am assuming is actually: func scaleAndCropImage( image: UIImage, toSize size: CGSize, fitImage: Bool = false ) -> UIImage { > On May 31, 2016, at 3:27 PM, Hooman Mehr via swift-evolution > <swift-evoluti

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

This arises a different question: Should `description` always return the same value? For example: Can `description` of “May 31th, 2016” return “Today” if we evaluate it today and return “Yesterday” if we evaluate it tomorrow? Are such side-effects (using a volatile global value) permitted? Then

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

Syntax by itself is not clear enough. Appending Initializable makes it too long. We can replace Syntax with LiteralSyntax to clarify. Then we will have: extension MyNumber: LiteralSyntax.Integer, LiteralSyntax.Float { /*…*/ } Better yet, to address the valid concern of doing something so

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

e`? > > On Sun, Jun 26, 2016 at 11:11 AM, Hooman Mehr via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Syntax by itself is not clear enough. Appending Initializable makes it too > long. > > We can replace Syntax

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0048: Generic Type Aliases

Strong +1 from me, too. With the exact response as Juan. It is among the top 10 on my wish list. > On Mar 24, 2016, at 11:18 AM, Juan Ignacio Laube via swift-evolution > wrote: > > What is your evaluation of the proposal? > A strong +1 on this. > > Is the problem

Re: [swift-evolution] Extending init checks for property initialization

Besides the ages old designated initializer pattern that is already suggested (having a few designated initializers and a bunch of convenience initializers), this is how I have been dealing with this since Swift 1.0: import UIKit import AVFoundation class SomeViewController: UIViewController {

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

Although handy for now, I am a bit concerned about moving `where` clause to the end of declaration. This reserves and occupies this wide open space at the end of declarations. I think we might find a better use for this space later as the language evolves. Any thoughts? > On May 10, 2016, at

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

I agree with adding more such API’s. Look at this gist for an implementation of a few more of what I find useful. You can add them to your proposal if you like them and I will be able to help better shape it up. Here is a

Re: [swift-evolution] [RFC] #Self

> On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution > wrote: >> That said, I’m not sure I understand the concrete use-cases. When is this >> concept important? When is “Self” not good enough? > > The only case where there is new functionality is

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

Thank you for your comments. I think additional index manipulation and collection scanning API is needed, and your proposal cover an important part of it. I also have some clarifications and comments inline: > On May 10, 2016, at 4:52 PM, Nate Cook wrote: > Thanks Hooman!

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

How about a more radical change that eliminates this entire concern and keeps the whole generics declarations in one place: Move the entire generic declaration with its brackets somewhere other than between function name and its parameters. I know this breaks the “norm”, but what do you

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Exactly: I also consider synchronous dispatch a special case not worthy of sacrificing a better name (`dispatch`) for it. I prefer to have a single `dispatch` as the main function name. Here is my proposed modified signature based on the proposal

Re: [swift-evolution] [Review] SE-0124: `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

+1 Same answers. > On Jul 15, 2016, at 10:54 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > * What is your evaluation of the proposal? > > +1 > > * Is the problem being addressed significant enough to warrant a > change to Swift? > >

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

> * What is your evaluation of the proposal? +0.5 > * Is the problem being addressed significant enough to warrant a > change to Swift? Almost > * Does this proposal fit well with the feel and direction of > Swift? I am not totally happy with the whole

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 14, 2017, at 1:24 AM, Slava Pestov via swift-evolution > wrote: > >> 3. When a protocol composition type contains a typealias, the validity of >> the type is determined using the following steps: >> >> Expand the typealias >> Normalize the type by removing

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution > wrote: >> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution >> > wrote: >> Looks good. Minor comments below: >> The typealias

Re: [swift-evolution] Nil-rejection operator

Two more tiny overloads is all takes to fix it: func ??(lhs: T?, rhs: T) -> T { if let lhs = lhs { return lhs } else { return rhs } } func ??(lhs: T?, rhs: U) -> Error { if let lhs = lhs { return lhs } else { return rhs } } > On Feb 9, 2017, at 12:01 PM, Jack Newcombe

Re: [swift-evolution] Strings in Swift 4

> On Feb 9, 2017, at 3:11 PM, Dave Abrahams wrote: > > > on Thu Feb 09 2017, "Ted F.A. van Gaalen" wrote: > >> Hello Shawn >> Just google with any programming language name and “string manipulation” >> and you have enough reading for a week or so :o) >> TedvG > > That

Re: [swift-evolution] Strings in Swift 4

> On Feb 9, 2017, at 6:50 PM, Shawn Erickson wrote: > > > > On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr > wrote: >> On Feb 9, 2017, at 3:11 PM, Dave Abrahams > > wrote: >> >> >> on

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

By its classic definition, a function that has inout parameters is not pure. So, again by classic definition, it should have a return value to have any use. But things can quickly get murky if we try to enhance and extend the meaning of pure. Then it becomes important to see at what level of

Re: [swift-evolution] Nil-rejection operator

I think the best solution is overloading the existing ?? operator. It is very easy to do: func ??(lhs: T?, rhs: U) throws -> T { if let lhs = lhs { return lhs } else { throw rhs } } then you can say: do { let y = try x ?? myError } catch ... It might even

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

+1, basically the same response as Matt’s. > On Feb 28, 2017, at 1:51 PM, Matthew Johnson via swift-evolution > wrote: > >> >> What is your evaluation of the proposal? > +1. Checking things off the list of items on the generics manifesto is > always great to see,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

> On Feb 28, 2017, at 1:19 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md > >

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

Strong +1. I really need this feature to improve and simplify my existing code. > On Sep 23, 2016, at 5:50 PM, Austin Zheng via swift-evolution > wrote: > > * What is your evaluation of the proposal? > > +1. I very much want to see this in Swift, and it seems like

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On Nov 6, 2016, at 8:03 PM, Dave Abrahams via swift-evolution > wrote: >> I had a brush with Julia > as >> well. Have you >> looked at their work > > It's been a while, to be honest. > >> and the recent reworking of

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

Yes, this is a very important issue to consider before we freeze them. As part of my Swift hobby, I have worked a bit on a Swifty wrapper for linear algebra packages and also toyed a bit with the merits of a Swift implementation of some of the related algorithms and data structures (such as

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

I don’t think $ will be become available to be used as an operator if we remove its identifier use. > On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution > wrote: > > Agree with Robert here. I'd rather be able to use it as part of operators. > Currently

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

+1. I am in favor of keeping and documenting single dollar sign as a valid identifier. I personally find it very convenient to have it as a valid identifier, although I don’t use Dollar library. > On Oct 14, 2016, at 12:59 PM, Chris Lattner wrote: > > Hello Swift

Re: [swift-evolution] Some clarity lost from the great renaming

Is changing the mapping of Cocoa API considered a source breaking change or can we report such incidents as bugs if we think they don’t match API guidelines? > On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Oct 18 2016, Brandon

Re: [swift-evolution] Implicit Optionals for Tuples & Tuples as Function Parameter

Since Swift 3.0, they are no longer a normal type like Optional. See SR-0054 > On Nov 11, 2016, at 11:54 AM, Muhammad Tahir Vali via swift-evolution > wrote: > > Im curious to know

Re: [swift-evolution] guard let x = x

> On Nov 2, 2016, at 2:02 PM, Matthew Johnson via swift-evolution > wrote: >> On Nov 2, 2016, at 3:47 PM, Sean Heber via swift-evolution >> > wrote: >> >> For what it’s worth, I concur. I think type

Re: [swift-evolution] private & fileprivate

fileprivate is not essential but I also would like to defend keeping it, at least for now. I find it useful in practice. In some cases, I can’t put a declaration in the global file scope (where fileprivate and private are essentially the same thing). For example, for organizational reasons I

Re: [swift-evolution] [Pitch] Adding in Optional Argument labels for completion handlers

This is an unfortunate side effect of another important and necessary change: Making argument labels part of functions name. This means that closures (which are anonymous functions and lack a function name) now don’t have any place to keep the argument labels. Using a labeled tuple as a

Re: [swift-evolution] Generic types―covariance/contravariance

it that narrow - monadic types like Optional also benefit > from variance: > > func p(_ data:Any?) { > if data != nil { > data.map { print($0) } > } > } > var a:String? = "foo" > p(a) > // -> “foo" > > > -DW > >> On Dec 9,

Re: [swift-evolution] Generic types―covariance/contravariance

For the specific case of custom collections, I think it is worth providing a protocol as Doug noted before. Quoting Doug Gregor (1/13/16, thread: "Make generics covariant and add generics to protocols”): > Swift’s value-semantic collections are covariant in their generic parameters, > which

Re: [swift-evolution] It's the little things..

> On Dec 14, 2016, at 11:08 AM, David Sweeris via swift-evolution > wrote: > I'll be curious as to how they propose we prevent collisions between > Optional.none.hashValue and any given T's hash value. It is a hash, collision is fine. It is just a single value. I

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

+1 on the third option it being clearly the best way to model pointers. Making the index strideable makes its use in index computations easy. It takes a bit care to make it work as conveniently for UnsafeBufferPointer where the stride will need to be special. > On Dec 1, 2016, at 11:33 PM,

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

How about providing an Int subscript in addition to switching the index type for the purpose of Subsequence? > On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution > wrote: > > >> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution >>

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 29, 2017, at 3:00 PM, Douglas Gregor via swift-evolution > wrote: > > > * @implicitobjc added to a class implicitly makes members of that class *and > all of its subclasses* @objc if they can be exposed to Objective-C > * @implicitobjc added to a class

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1 Having the feature is worth the oddities of the syntax. > On Apr 5, 2017, at 4:01 PM, Douglas Gregor via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > >

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

+1 with this clarification / revision > On Apr 6, 2017, at 5:34 PM, Ben Cohen via swift-evolution > wrote: > > >> On Apr 5, 2017, at 10:32 PM, Félix Cloutier > > wrote: >> >> During the proposal phase, we asked how

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

+0.5 Positive on multi-line string literal Negative on the delimiter. I don’t like continuation character, but would like to have something similar to classic C comments: distinct, symmetrical opening and closing delimiters. But I don’t have any specific suggestion. > On Apr 7, 2017, at

Re: [swift-evolution] [Review] SE-0164: Remove final support in protocol extensions

Agreed. +1 > On Apr 6, 2017, at 11:51 AM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

Similar observation on my side as well. Certainly it is better to specify the class constrain (or the type alias that has the class constrain) first because (sub)class constrain is the most determining factor about the nature of the declaration, but I think it is too hard to enforce properly

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Maybe we need more than one level of standard library: The core (which is most of what we have now (but maybe not all of it) and multiple opt-in standard modules for hash functions, math, specialized data structures, etc. > On Jul 31, 2017, at 11:10 AM, Taylor Swift

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I prefer an approach that preserves how I am used to seeing math expressions. I use this myself: protocol FloatingPointMath: FloatingPoint { static func sqrt(_ value: Self) -> Self static func sin(_ value: Self) -> Self static func cos(_ value: Self) -> Self static func tan(_

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I know. I hear you. I have some special arrangmnents to keep such things manageable, and I am not happy about how things stand right now. What I am hoping to open up stdlib special compiler mode to other (low-level) libraries and also letting such libraries gain optimizations similar to stdlib

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Considering these observations and more from Brent and Dave, I support ultimately making KeyPath) a subtype of (T)->U as suggested. If someone really wants this now, I would go with a prefix operator as a stopgap: prefix operator ~ prefix func ~(lhs: KeyPath) -> (T)->U { return

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

I like this promote operator idea. I have been defining similar operators for specific projects almost at random. It makes sense to come up with a well-defined behavior and name for such operators, as a common practice as you suggest. The problem with the postfix operator is that it does not

Re: [swift-evolution] [Pitch] Computed properties as aliases

This is common when you are using façade design pattern. You use a façade to flatten and hide the internal composition of a composite object and present it as a single flat object. In some types of projects this comes up rather frequently. Both in client / UI programming and server side /

Re: [swift-evolution] [Pitch] Computed properties as aliases

May 25, 2017, at 9:26 PM, Hooman Mehr via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> This is common when you are using façade design pattern. You use a façade to >> flatten and hide the internal composition of

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

Overall, I am strong +1 on this, but I don’t have time to go through a detailed analysis of how it will affect my own use cases. > On Jun 4, 2017, at 4:29 PM, Ted Kremenek via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0180 "String

Re: [swift-evolution] [Pitch] UnsafePointer.advanced(to:)

> On Jun 6, 2017, at 12:56 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jun 06 2017, Brent Royal-Gordon > wrote: > >>> On Jun 6, 2017, at 9:06 AM, Xiaodi Wu wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Remove ownership keyword support in protocols

+1 After a quick read, I don’t think this issue needs a review: It is just a compiler bug. > On Sep 20, 2017, at 1:11 PM, Ted Kremenek wrote: > > The review of “SE-0186: Remove ownership keyword support in protocols” begins > now and runs through September 27. > > The

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

Thank you Pierre for writing this. I wanted to say this for a while, but I am too busy these days to do it myself. Guys, please don’t miss what he has to say: > On Aug 31, 2017, at 5:49 PM, Pierre Habouzit via swift-evolution > wrote: > > On real systems going

Re: [swift-evolution] Adding Result to the Standard Library

You can support all styles with enum as well. What don’t you do this: public enum Result { case value(T) case error(Error) public init(_ value: T) { self = .value(value) } public init(error: Error) { self = .error(error) } public func get() throws -> T {

Re: [swift-evolution] Adding Result to the Standard Library

ue(try closure()) } catch { self = .error(error) } } > On Nov 14, 2017, at 6:57 PM, Hooman Mehr via swift-evolution > <swift-evolution@swift.org> wrote: > > You can support all styles with enum as well. What don’t you do this: > > public enum Result { >

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

+1 Agree with Chris with Doug’s suggestion to amend SE-0143 to document it. > On Nov 22, 2017, at 10:08 AM, Douglas Gregor via swift-evolution > wrote: > On Nov 22, 2017, at 9:48 AM, Chris Lattner > wrote: > >> IMO

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

+1 It should have been like this from the get go. > On Nov 14, 2017, at 11:31 AM, Ted Kremenek wrote: > > The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now > and runs through November 21, 2017. > > The proposal is available here: > >

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

>> } >>> >>> class C : P, Initable { >>> required init() {} >>> } >>> >>> Now imagine you could do this, >>> >>> let x: P & AnyObject >>> >>> x.f(12) >>> >>> Th

[swift-evolution] Preserving non-mutability of methods of an existential or generic object

The title is confusing, let me clarify by example: We have this protocol with a mutating method: protocol P { mutating func f(_ x: Int) -> Int } And a conforming class (which has to conform with a non-mutating method): class C: P { func f(_ x: Int) -> Int { return x } } An instance of this

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Excellent Idea! I am all for this. It shouldn’t be too complicated to add a second implicit import and only code that is actually using this stuff will have increased code size. > On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution > wrote: > >

Re: [swift-evolution] Incremental ABI stability

I think the best solution is Chris Lattner’s suggestion (responding to DictionaryLiteral) to split the shaky stuff into an overlay for Swift standard library to maintain compatibility. > On Jan 10, 2018, at 2:12 PM, Greg Parker via swift-evolution > wrote: > > >>

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

I think this type might become more useful if we find a good name for it and better document it. For example, it is a natural fit for parameter list of Chris’ callable type proposal. Since this type accepts duplicate “keys” and does not provide key-based lookup, the first thing that deserves a

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

A strong +1 on this approach instead of the current revision of SE-0194. This is a very focused solution to a very focused need. It sidesteps the issues of a protocol based approach (potential for abuse or deciding/defining the intended uses of such protocol). Also, we already have the

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

For people who don’t read all the way down, here is the gist of what Chris is saying: > 1. The vast majority of the standard library goes into the OS. This includes > all the string, array, and other stuff people use. > 2. The deprecated wrappers and obscure APIs go into a new module, and that

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

uld do this, > > let x: P & AnyObject > > x.f(12) > > This would be invalid because ‘x’ is a let binding but the requirement ‘f’ is > witnessed by the protocol extension method, which performs a mutating access > of ‘self’. > > Slava > >> On D