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

I completely disagree with what you said. It sounds extreme to me to release a v1 of a library without giving yourself the flexibility to iterate on it beforehand. > On 11 May 2016, at 08:30, Drew Crawford via swift-evolution > wrote: > > I'm one of the largest

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

I like those a lot. Crystal clear. > On 11 May 2016, at 05:14, Patrick Smith via swift-evolution > wrote: > > How about: > > Consuming (from) > Producing (to) > > > IntegerLiteralConsuming > StringLiteralConsuming > > CustomStringProducing >

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

> On 11 May 2016, at 01:02, Matthew Johnson wrote: > > Thanks for your feedback. > > To be honest, I'm not a fan of the names you suggest. Erica had a similar > variation using To, From, and ToAndFrom prefixes that I find preferable to > your suggestions if we were

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> * What is your evaluation of the proposal? -1. Even if I see the arguments in favour, I am of the same opinion as Tony Allevato and Chris Latner: tuples and parameter lists are most often fixed size, which reduces the usefulness of this proposal. And if the proposal is accepted, where

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> * What is your evaluation of the proposal? I think the proposal is worthwhile and I see myself using those when writing multiplatform code. I agree that they are much less brittle than os tests. > * Is the problem being addressed significant enough to warrant a change > to Swift?

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

> * What is your evaluation of the proposal? +1 for the idea of making the naming consistent -1 for the actual chosen names Even after reading the reasoning behind the choice of those words, it took me a time to scratch my head around it. It’s definitely not immediately obvious that

Re: [swift-evolution] NSRange and Range

und? Could we migrate those APIs to return an >> Optional Range? > > If you had annotations on the APIs to say that they use NSNotFound as a > sentinel, yes. > > - Doug > >> >>> On 10 May 2016, at 05:49, Douglas Gregor <dgre...@apple.co

Re: [swift-evolution] NSRange and Range

Why wouldn't it completely eliminate NSRange? Are you thinking of NSNotFound? Could we migrate those APIs to return an Optional Range? > On 10 May 2016, at 05:49, Douglas Gregor <dgre...@apple.com> wrote: > > >> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

>* What is your evaluation of the proposal? +1 This proposal makes the package manager a first-class tool, instead of a set of command options. >* Is the problem being addressed significant enough to warrant a change to > Swift? It should be addressed before it goes public. >*

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

> What is your evaluation of the proposal? +1 I already gave my opinion in the original discussion but I’ll summarise it here. I understand the fears that this proposal may inhibit us in the future from making the modifications that Foundation needs to make it feel more Swifty. But I think

Re: [swift-evolution] Typealiases in protocols and protocol extensions

migrate my code to your proposed >>>> version of Swift? >>>> >>>> This is a toy example, of course. More generally, though, I wonder about >>>> this question: >>>> >>>> Suppose two protocols A and B each declare type

Re: [swift-evolution] Typealiases in protocols and protocol extensions

direct >>> associated types. But are they themselves considered protocol requirements? >>> >>> I ask because, suppose I want to conform type T to A and B. I implement all >>> the required methods and properties for such conformance. I declare the >>> ap

Re: [swift-evolution] Typealiases in protocols and protocol extensions

. I declare the >>> appropriate typealiases for the associatedtypes declared in both protocols. >>> But, if A.Element and B.Element are incompatible with each other, it is >>> nonetheless impossible to conform T to both A and B? If it's forbidden, >>> isn't that kind

Re: [swift-evolution] Typealiases in protocols and protocol extensions

to both A and B? If it's forbidden, >> isn't that kind of a bummer, since what's getting in the way is a naming >> clash arising from a facility intended to simplify the naming of things >> rather than provide for new functionality? If it's permitted, what is >> T.Element

[swift-evolution] Typealiases in protocols and protocol extensions

Hello, I’ve come again with another proposal directly from the Generics Manifesto. Please let me know if it needs any modifications before sending the pull request. Typealiases in protocols and protocol extensions Proposal: SE-

Re: [swift-evolution] [Manifesto] Completing Generics

> On 09 May 2016, at 00:38, Austin Zheng wrote: > > Is the plan to eventually support "multiple" forms of concrete same-type > requirement syntax - the existing "where Element == SomeConcreteType" and the > generic parameterized extensions described elsewhere? If not,

Re: [swift-evolution] [Manifesto] Completing Generics

at 23:17, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > I created two bug requests for Recursive protocol constraints and Nested > generics and will write a proposal for Concrete same-type requirements. > > [SR-1445] Recursive protocol constraints &g

[swift-evolution] NSRange and Range

Hello Swift-Evolution, I spent some time coding on Linux with Swift 3 (latest developement snapshot) and corelibs-foundation and I’ve hit one major hurdle: passing and converting NSRange and Range around between the different stdlib and Foundation APIs - specifically in regards to String. Is

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

gt; Sent from my iPad > > On May 6, 2016, at 1:29 AM, David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> If we are discussing naming changes to reduce, here's my personal opinion: >> >> * When I f

Re: [swift-evolution] Making `.self` After `Type` Optional

I understand why the alternative of changing the generic type parameter list symbols was rejected, to be consistent with other C based languages, but I don't understand why the following was rejected: making the UppercaseTypes, lowercaseValues convention a syntactic requirement, as is done in

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

If we are discussing naming changes to reduce, here's my personal opinion: * When I first encountered it, I understood exactly what it did because I knew that term of art. If it was named sequence, I would have been confused. * If we are discussing name changes, I'd personally vote to change it

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

he intended name lookup semantics. Does name >>>> lookup for "AssocType" start its lookup in R or in Q? If the former, can >>>> one refer to an associated type newly defined in R? >>> >>> To me this syntax reads as a constraint on Q only. I

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

Same, -1 from me. I’m not saying its a bad idea, just no worth polluting the standard library. > On 05 May 2016, at 06:06, Chris Lattner via swift-evolution > wrote: > > On May 4, 2016, at 1:35 PM, Jordan Rose via swift-evolution >

Re: [swift-evolution] multi-line string literals.

> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution > wrote: > > it's not a secret that I'm not a big fan of the proposal. The third draft > doesn't change this and it's unlikely that any future draft will, because for > me, the problem are the

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

>* What is your evaluation of the proposal? I like the proposal and I think it's a good idea, but I'm really not sure it is important enough to fix. Looking at the proposals already accepted, half of them are still waiting for an implementation. Several will probably never make it in time

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I know why: copy and paste :) Fixed btw. > On 03 May 2016, at 20:25, Dave Abrahams via swift-evolution > wrote: > > > on Mon May 02 2016, David Hart wrote: > >> Hi Doug, >> >> In the latest version of the proposal, which is now linked

Re: [swift-evolution] [Manifesto] Completing Generics

I’d like to continue moving Completing Generics forward for Swift 3 with proposals. Can Douglas, or someone from the core team, tell me if the topics mentioned in Removing unnecessary restrictions require proposals or if bug reports should be opened for them instead? > On 03 Mar 2016, at

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

enough? David. > On 26 Apr 2016, at 05:28, Douglas Gregor <dgre...@apple.com> wrote: > > >> On Apr 24, 2016, at 1:34 PM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I wrote th

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

of the > associatedtype declarations as they are effectively peers in the same type > constraint. Allowing such constraints to stand alone would look similar to > Doug's example in the issues section. I would prefer to look for a syntax > for generic constraints on declarations that allow

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

I got the reference, made me laugh :) > On 03 May 2016, at 00:21, Erica Sadun via swift-evolution > wrote: > > >> On May 2, 2016, at 4:15 PM, Chris Lattner > > wrote: >> >>> >>> On May 2, 2016, at 2:48 PM, Erica

Re: [swift-evolution] [Idea] Remove optional pattern binding

John, When the core team implemented the `if let x? = y` experiment and later backtracked, were you enthusiastic about it? The way Jordan puts it "Yeah, as nice as it sounds, it didn’t work out in practice.” sounds very definite, as if it was an obvious and unanimous decision to backtrack. I

Re: [swift-evolution] throw expressions in ternary operators

Correct, it is not ternary, just a slip of my mind :) > let age = try dictionary["age"].flatMap { elem in > try elem as? Int ?? { throw Error() }() > } I didn’t know this workaround worked. Cool! Can somebody from the core team tell us if it not supporting throw directly is a bug or an

[swift-evolution] throw expressions in ternary operators

I remember discussing something like this in swift-evolution but can’t find it. I was wondering if it was worth a proposal or not. When constructing objects from dictionary of values, I often write the parsing of optional values as such: age = try dictionary["age"].flatMap { if let age

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

Nice catch! > On 02 May 2016, at 11:58, Dany St-Amant via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello > > You have an extra where dangling in the from example > > Dany > > Le 2 mai 2016 à 03:16, David Hart via swift-evolution > &

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

Name updated: https://github.com/apple/swift-evolution/pull/281 > On 02 May 2016, at 09:39, David Hart wrote: > > I'll update the proposal ASAP :) Btw, wasn't sure if you wanted to be cited > as co-author because I did not have your express approval, but I thought it > was

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

I'll update the proposal ASAP :) Btw, wasn't sure if you wanted to be cited as co-author because I did not have your express approval, but I thought it was the right thing to do. Was in a bit in a hurry to send the Pull Request before going to work. > On 02 May 2016, at 09:20, Developer

[swift-evolution] Move where clause to end of declaration

Hello swift-evolution, I took the pitch originally from Developer to move the where clause out of the generic parameter list, with improvements brought up by Pyry Jahkola, and wrote a proposal for it. I opened a Pull Request, but if anybody wants to bring some modifications to it before it is

Re: [swift-evolution] multi-line string literals.

Same here. IMHO, there needs to be a version of multi line strings that's doesn't require to prefix a token on each line. > On 30 Apr 2016, at 09:20, Daniel Phillips via swift-evolution > wrote: > > Sorry for any extra noise here. I've read the 58 emails in this

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

What’s up with this great idea? Can’t see a proposal on swift-evolution anywhere. > On 08 Apr 2016, at 08:15, Chris Lattner via swift-evolution > wrote: > > >> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution >> wrote: >> >>

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

But Collection has to have an extension which explicitly mentions IndexingIterator: extension Collection where Iterator == IndexingIterator { /// Returns an iterator over the elements of the collection. public func makeIterator() -> IndexingIterator { return

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

griboz...@gmail.com> wrote: > > On Fri, Apr 29, 2016 at 12:25 AM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: >> I’ve taken some time to digest the current feedback and I’ve changed my >> mind. The syntax for adding constraints to a sub-proto

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

> * What is your evaluation of the proposal? +1 The new API conventions for member references (especially enums) seem broken without this proposal IMHO. > * Is the problem being addressed significant enough to warrant a change > to Swift? I think it is paramount. > * Does

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

> * What is your evaluation of the proposal? +1 I’ve always been bothered with the idea of Foundation becoming a first-class cross-platform library while breaking the core principles of Swift promoting value types. I’m extremely happen with this proposal. > * Is the problem being

[swift-evolution] [Proposal] More Powerful Constraints for Associated Types

I wrote the proposal which was discussed to introduce generic constraints for associated types. I’d like to get some feedback on it and get it ready before submitting it: More Powerful Constraints for Associated Types Proposal: SE-

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

If the original rationale is gone, shouldn’t we also get rid of the empty tuple-type and replace it by a full-blown Void instead of Void being a typealis for the empty tuple? (Int) -> Float (String) -> Void () -> Void () -> Double It looks more consistent to me. > On 15 Apr 2016, at

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

Why? What guideline are you referencing? > On 15 Apr 2016, at 09:53, Jacob Bandes-Storch via swift-evolution > wrote: > > Was the syntax fully bikeshedded by the core team before acceptance? Perusing > the API guidelines, one could also imagine: > >

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

I wouldn't mind driving the discussion and proposal, because I'd really like to see a more complete generics system. Before I start, can David or Doug, or someone else with a high-level view of the generics system tell me if this is where to start or if there is another feature in the Complete

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

Hi Doug, I've read the discussion about moving the where clause to the right of declarations (which I full-heartedly approve) but I don't see how it would have any impact on the syntax of associated types requirements. David > On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution >

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Totally agree with Brent, map/flatMap are terms of art. Sent from my iPad On 10 Apr 2016, at 23:11, Brent Royal-Gordon via swift-evolution wrote: >> I still don’t see what’s being lost here, it’s not like the proposal is to >> radically rename them, all we’d end up

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

There's something I find very confusing with this proposal, and it's how Self is already used in protocol definitions to represent the STATIC type of the type that conforms to the protocol. I think people will be potentially very confused by how Self represents different types in different

Re: [swift-evolution] Proposal Discussion Thread: SwiftPM: Locking and Overriding Dependencies

I think TOML is no-go as its readme says: Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly. And I agree about YAML: no parser, more work, and more complicated. JSON sounds like a sane format. > On 04 Apr 2016, at

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Hello Matthew, If the goal is to make rules for accessing static members and enum cases more consistent, why can’t static members be accessed from inside the type cope with a dot prefix (sorry for the grim example)? struct Person { static let lifeExpectency: Int = 80 let age: Int

Re: [swift-evolution] SE-0025: Scoped Access Level, next

I’m fairly sure what you are asking for already exists with @testable: https://www.natashatherobot.com/swift-2-xcode-7-unit-testing-access/ > On 01 Apr 2016, at 23:04, John Heerema via swift-evolution > wrote: > > I’m a fan of test-driven development. > I use it

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

> What is your evaluation of the proposal? -1 I admire the goal of making trailing closures usably in guard, but I do not like the inconsistency between guard and if. I also never liked the inconsistency with the else keyword in guard. Bother those reasons means that I’m worried that this will

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Perhaps it's because I'm not a native English speaker, but interfile doesn't read well at all to me whereas fileprivate is crystal-clear. > On 31 Mar 2016, at 08:21, T.J. Usiyan via swift-evolution > wrote: > > public > internal > (fileprivate | interfile) > private

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I love those. And internal corresponds to the meaning it has in other languages. +1 > On 31 Mar 2016, at 06:22, Chris Lattner via swift-evolution > wrote: > >> On Mar 23, 2016, at 10:13 PM, Chris Lattner wrote: >> How about we continue this

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I like it very much. > On 24 Mar 2016, at 06:13, Chris Lattner via swift-evolution > wrote: > > How about we continue this trend, and follow other existing Swift keywords > that merge two lowercase words (associatedtype, typealias, etc), and use: > > public >

Re: [swift-evolution] [Discussion] Referencing the Objective-C selector of property getters and setters

Wouldn't it be: #selector(getter: NSString.lowercaseString)) To allow us to disambiguate getters and setters? > On 15 Mar 2016, at 06:09, Keith Smiley wrote: > > Another reasonable use case for this is with `UILocalizedIndexedCollation`. > For example with Swift 2.1:

Re: [swift-evolution] [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

To bring a little bit more context: I copied this Regex library in my project which had StringLiteralConvertible and implemented the pattern matching operator and all of a sudden, ALL init(rawValue: String) calls of completely unrelated enums started returning unexpected values. If I did not

Re: [swift-evolution] [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

ase (no pun intended), the switch cases are converted to SomeStringLiteralConvertibleType and then pattern matched. But shouldn't the implementation of switch refrain from any complicated casting when the types correspond? David. > On 06 Jan 2016, at 10:20, David Hart via swift-evolution >

Re: [swift-evolution] [swift-users] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

I can file those bugs. Would it be beneficial if I also created failing unit tests? David. > On 06 Jan 2016, at 20:05, Joe Groff wrote: > >> >> On Jan 5, 2016, at 9:28 AM, David Hart via swift-users >> > wrote: >> >> How

Re: [swift-evolution] [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

Sorry about the double post. > On 05 Jan 2016, at 18:26, David Hart via swift-users > wrote: > > How is it that Swift allows code like this: > > struct Sneaky: StringLiteralConvertible { > init(stringLiteral value: String) {} >

[swift-evolution] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

How is it that Swift allows code like this: struct Sneaky: StringLiteralConvertible { init(stringLiteral value: String) {} init(extendedGraphemeClusterLiteral value: String) {} init(unicodeScalarLiteral value: String) {} } func ~=(sneaky: Sneaky, string: String) -> Bool {

<    1   2   3   4   5   6