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

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 {

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] SE-0064 Property Selectors and KVO

#selector(Thing.thingWatched) won't work because it expects a function. As thingWatched is a property, it doesn't know if you want to reference the getter or setter. SE-0064 lets you reference those explicitly. In this case, you could write NSStringFromSelector(#selector(getter:

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

ous if there was going to be a >> meet up, either formal or informal. Sounds good. >> >> -Rod >> >> On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >&g

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

The clarification seems pretty clear to me, and they stated it: "to preserve higher-level consistency throughout the language in how components of expressions and statements are separated" > On 09 Jun 2016, at 09:53, Haravikk via swift-evolution > wrote: > > >> On

[swift-evolution] WWDC Meetup

I imagine that during WWDC a non-negligible proportion of the Swift Open Source contributors will be in or around San-Francisco. I’d very much like to profit from that opportunity to meet-up, get to know each other, talk Swift over some beers! Is anybody interested? If yes, any ideas for

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

> • What is your evaluation of the proposal? +1 I’ve always been annoyed by the complicated grammar of condition clauses. This proposal simplifies them and makes them easier to understand and teach. Especially, I regret that the syntax for A && B is different than B && A when A is a

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

+1 for the bottom type > On 08 Jun 2016, at 07:45, L Mihalkovic via swift-evolution > wrote: > > >> On Jun 8, 2016, at 6:57 AM, Thorsten Seitz wrote: >> >> I strongly disagree. Type systems are not some esoteric academic thing only >> working

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

) sounds fun! >> >> Shane >> >> On Jun 6, 2016, at 4:56 AM, Rod Brown via swift-users <swift-us...@swift.org >> <mailto:swift-us...@swift.org>> wrote: >> >>> I'd be interested in catching up. Was curious if there was going to be a >>&g

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

. My original wording wasn’t entirely clear. So, if you like Swift, if you have an interest in discussing about the Open Source project, please feel welcome to subscribe! David. > On 07 Jun 2016, at 08:46, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

-1 I have similar concerns on the mental ambiguity of the direction this is going. > On 10 Jun 2016, at 22:15, Thorsten Seitz via swift-evolution > wrote: > > -1 > >> Am 10.06.2016 um 21:10 schrieb Brent Royal-Gordon via swift-evolution >>

Re: [swift-evolution] Add max/min to floating point types

Agree with all you said > On 11 Jun 2016, at 02:20, Darren Mo via swift-evolution > wrote: > > Thanks for the summary of the arguments against max/min! Comments inline. > >> On Jun 10, 2016, at 6:51 PM, Stephen Canon wrote: >> >>> On Jun 10,

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> +1 I'd love to put some faces to some names :) sounds fun! >>> >>> Shane >>> >>> On Jun 6

[swift-evolution] [Pitch] Remove associated type inference

Here’s a pitch for removing associated type inference as per the Generics Manifesto. If we want to do it, we’d better do it before Swift 3: Remove associated type inference Proposal: SE-

Re: [swift-evolution] [Pitch] Remove associated type inference

> On 25 May 2016, at 23:47, Dmitri Gribenko <griboz...@gmail.com> wrote: > > On Wed, May 25, 2016 at 2:43 PM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: >> Impact on Existing Code >> >> This is a breaking change that

[swift-evolution] [Pitch] Allow explicit specialization of generic functions

Hello, This is a new pitch to allow explicitly specializing generic functions. Notice that potential ambiguity with initialisers and how I’m currently trying to avoid it. Please let me know what you think! David Allow explicit specialization of generic functions Proposal: SE-

Re: [swift-evolution] [Pitch] Remove associated type inference

I'm not quite sure I follow you. I am suggesting only removing it for associated type inference, where we fairly rarely benefit from it compared to general type inference. > On 26 May 2016, at 00:42, Leonardo Pessoa wrote: > > If the issue is easing the work of the

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now. > On 28 May 2016, at 09:03, Brian Christensen via swift-evolution > wrote: > > On May 27, 2016, at 13:57, Adrian Zubarev via

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

Yet another alternative: would it be possible to disallow commas as variable declaration separators and use them for condition clause separators again: let a = 4, b = 8 // becomes illegal and requires to separate them on two lines if a > 4, let c = foo(), let d = bar(), c != d { // now comma is

Re: [swift-evolution] Access modifier blocks

I dont agree. I think extensions serve this purpose very well. Here is what I do: I start with the type declaration only containing properties (public or private). I then create one extension per access level required and one per protocol conformance and per superclass overrides. We get:

Re: [swift-evolution] Access modifier blocks

And if you want to be able to declare properties in extensions, which I'm not a fan of, I think it would still be more a appropriate proposal than one that adds another way to group access modifiers. > On 14 Jun 2016, at 13:18, David Hart via swift-evolution > <swift-evolution@swift.o

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

I'm against using Nil as it would have a very different meaning than Nil (or Null) in all other C-based languages. > On 06 Jun 2016, at 05:56, Charlie Monroe via swift-evolution > wrote: > > Adding a Nil *type* is a bit different than casting dozen of identifiers to

Re: [swift-evolution] [Pitch] Property reflection

I'm talking of model objects that serializes certain properties (not necessarily all) that should have their setter be private/hidden for encapsulation reasons: struct Person { private(set) var birthdate: NSDate } I'm not a fan of adding an attribute like private(reflectable). The proposal

Re: [swift-evolution] [Pitch] Remove associated type inference

can do this without the compiler > complaining: > > struct SomeGenericGenerator : GeneratorType { > mutating func next() -> Element? { > return nil > } > } > > So I’d like to see the above `typealias Element = Element` allowed if > possible. > >

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

ark Lacey <mark.la...@apple.com> wrote: > > >> On May 25, 2016, at 4:17 PM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello, >> >> This is a new pitch to allow explicitly specializing generic functions. &g

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

Yes, it matches the order of the generic parameters. I'll mention it explicitly in the next version. > On 26 May 2016, at 03:50, Patrick Smith wrote: > > Sounds good to me. So it matches the order of the generic parameters? > > e.g. > > func foo(t: T, u: U) { … } >

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

for 2-5 inputs > func >>> <In, In2, Out>(deduce: (In.Type, In2.Type), fn: (In, In2) -> Out) -> > (In, In2) -> Out { > return fn > } > > // Output type deduction operator > func >>> <In, Out>(fn: In -> Out, deduce: Out.Type) -> In

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

> Out) -> (In, In2) >>> -> Out { >>> return fn >>> } >>> >>> // Add versions for 2-5 inputs >>> func >>> <In, In2, Out>(deduce: (In.Type, In2.Type), fn: (In, In2) -> Out) >>> -> (In, In2) -> Out { &g

Re: [swift-evolution] [Pitch] Remove associated type inference

bout >> why we’re considering this change than I see in this proposal. >> >> Are there any benefits users might receive from this change (assuming type >> checker architecture and bugs could eventually be ironed out)? Is it >> actively blocking desirable new features?

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

> - If its conformers produce a value-preserving representation, would it make > sense for it to also have an initializer accepting the value? What > specifically makes it value preserving otherwise? This makes sense to me. But we are getting dangerously close to a Serialization feature which

Re: [swift-evolution] Enhanced existential types proposal discussion

Hi Austin, I never had te occasion to say thanks for the work you have put in this proposal, so thanks! I’m really looking forward to be able to have some form of it accepted and implemented in Swift. Here are a few comments: 1) Why would Any<> and Any be illegal? What error messages would

Re: [swift-evolution] [Pitch] Property reflection

> On 27 May 2016, at 04:44, Austin Zheng via swift-evolution > wrote: > > My personal preference would be to honor access control, and consider ser/de > separately (especially since there are so many other possible considerations > for that feature). Access

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

Yet another alternative: would it be possible to disallow commas as variable declaration separators and use them for condition clause separators again: let a = 4, b = 8 // becomes illegal and requires to separate them on two lines if a > 4, let c = foo(), let d = bar(), c != d { // now comma is

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now. > On 28 May 2016, at 09:03, Brian Christensen via swift-evolution > wrote: > > On May 27, 2016, at 13:57, Adrian Zubarev via

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

+1 again. > On 29 May 2016, at 21:39, Chris Lattner via swift-evolution > wrote: > >> On May 29, 2016, at 3:55 AM, Haravikk wrote: On May 27, 2016, at 12:11 PM, Joe Groff wrote: Hello Swift community,

Re: [swift-evolution] viewWill/DidAppear and viewWill/DidDisappear should have "animated" argument label (Victor Gao)

I think you need to write a bug report on bugreport.apple.com as it concerns an Apple Framework. But yes, I agree with you :) It does not follow the Swift API Design Guidelines. > On 22 Jun 2016, at 14:38, Victor Gao via swift-evolution > wrote: > > Hi all, > > In

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

-1 The Term of Art argument is very strong with these functions. I prefer them as-is. > On 16 Jun 2016, at 12:51, Patrick Pijnappel via swift-evolution > wrote: > > Due to considerably support on this thread >

[swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

I’ve only started using the transformed APIs from Apple frameworks that were auto-modified and I’ve found a few cases where the automatic translation doesn’t seem to follow the Swift Design Guidelines. I don’t know how much can be fixed manually, but if it can, it would be forth congregating as

Re: [swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

Inline for ease of read: CoreMotion CMMotionActivityManager Two modifications here: Remove the starting suffix as it only really pertains to the first argument. Rename the queue label to on to reduce

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

Entirely agree. \ makes total sense as the one-and-only escaping character. I also have no trouble typing it. > On 21 Jun 2016, at 23:55, Brent Royal-Gordon via swift-evolution > wrote: > >> I find that typing \(var) is very disruptive to my typing flow. The more I

[swift-evolution] IUO in Swift 3.0

Just saw this article about IUO in Swift 3.0: https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/ I was surprised that the IUO type still exists. From what I understood, SE-0054 gives a

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

> * What is your evaluation of the proposal? +1. This makes total sense. But I would recommend naming it “Never” for the same arguments as in the proposal. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes, it simplifies the language by

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

I’m not saying its necessarily *easy* to type, but I think its good enough to warrant the elegance of having only one escaping character instead of multiple. > On 22 Jun 2016, at 01:08, Brandon Knope via swift-evolution > wrote: > > Actually… we can go pretty

Re: [swift-evolution] IUO in Swift 3.0

Is there a bug tracking the remaining part of the implementation? Shouldn’t the proposal still be under “Not yet implemented” as its not completely implemented? David. > On 21 Jun 2016, at 22:22, Joe Groff <jgr...@apple.com> wrote: > >> >> On Jun 21, 2016, at 1:06

Re: [swift-evolution] Stdlib closure argument labels and parameter names

I did not pay a lot of attention to this renaming because I thought the trailing closure syntax would shield me from labels. But I forgot that in if/for/while statements, I’m going to be forced to use them. In those cases, I’d prefer more succinct labels. I added some comments inline where I

Re: [swift-evolution] Partial list of open Swift 3 design topics

> - Bridge NSRange to “Range?” I don’t think I can handle writing a proposal for this one, but I’d die for it. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> On 21 Jun 2016, at 01:52, Brent Royal-Gordon via swift-evolution > wrote: > > * I'm very uncomfortable with the amount of weight `accumulatingResultBy` > adds to `reduce`. `combinedBy` seems perfectly cromulent to me. I'm even more > concerned by your suggestion

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> * What is your evaluation of the proposal? +1 The protocols are well thought out and make total sense to me. I only have a miner gripe with the naming of: func nthWord(n: Int) -> UInt Which reads very weird. Why not: func word(at: Int) -> UInt > * Is the problem being

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

Most of your proposal look great to me! Comments inline: > On 23 Jun 2016, at 09:19, Brent Royal-Gordon via swift-evolution > > wrote: > > As previously threatened mentioned, I've written a draft proposal to fix a > number of naming

Re: [swift-evolution] Stdlib closure argument labels and parameter names

Comments inline: Sent from my iPhone > On 26 Jun 2016, at 00:25, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jun 22 2016, Erica Sadun wrote: >> >>> On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution >>>

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On 28 Jun 2016, at 10:14, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > What is `private` members were also visible to all extensions of the type in > the same module? PS: That solution would not allow operators to access private mem

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

Hello everybody, I tried using the access rules defined in SE-0025 in some code of mine to see what effect it would have. I came out of the experiment more disappointed than I thought. Here are several reasons: 1) The new rules make `private` more prominent compared to `fileprivate` (the

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Hadn't thought of roundUp/Down. Makes it so obvious. +10 > On 27 Jun 2016, at 18:32, Erica Sadun wrote: > > I'm with those recommending round, rounded, roundUp, roundedUp, roundDown, > roundedDown, with Remy's precision factored in as needed. > > This is usually the

Re: [swift-evolution] [Pitch] Remove type inference for associated types

Hi Matthew, I really like this proposal (even outside of its goal to simplify the type inference engine). The two other motivations in the proposal make very good points which can not be easily dismissed (especially to me as it took me a while to understand associated types): It improves the

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Whatever the naming scheme, I would be hesitant to have the non-mutating versions of floor and ceil have different endings, seeing how connected they are. So: floor, ceil floored, ceiled flooring, ceiling But not a mix. > On 27 Jun 2016, at 07:13, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] Optionals and nil in Switch statement

I don't see it as a bug. The if statement calls an equality function which promotes the lhs to an Optional (or that accepts a non optional as lhs - can't remember) but the switch statement does pattern matching. Does the the compiler warn you when pattern matching an optional with a

Re: [swift-evolution] [discussion] Fixing Protocols with Self or Associated Type Requirements

Things will get better once we have existentials. > On 29 Jun 2016, at 08:49, Robert Widmann via swift-evolution > wrote: > > Yes, the restriction "sucks", but it is there for a reason. A protocol is > not just a convenient collection of methods and properties you

[swift-evolution] Extend FloatingPoint with tau!

Hello community, Tau day was yesterday, and reminded me that we forgot to provide a `tau` next to `FloatingPoint`’s `pi` property. How about we write a proposal to brind this forward-thinking constant to a forward-thinking language? Proposal: Extend `FloatingPoint` with

Re: [swift-evolution] Optionals and nil in Switch statement

Perhaps it should provide a Fix-It, but I don't see it as an an issue, more as an opportunity to understand the pattern matching behind it :) > On 29 Jun 2016, at 08:59, Charlie Monroe wrote: > > Yes, you get a warning. But I don't see why it should - when you're

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] 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

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] 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] [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] [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] [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] [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] 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] [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

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-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

[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] [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] [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] [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] [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] 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] [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

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

I've been bit by this many times. A warning would really have helped me. > On 20 May 2016, at 07:06, Krystof Vasa via swift-evolution > wrote: > > Sorry, my previous example didn't use the string interpolation, it should be > >

Re: [swift-evolution] Enhanced existential types proposal discussion

It's actually a proposal waiting to be merged: https://github.com/apple/swift-evolution/pull/284 On 24 May 2016, at 04:52, Brent Royal-Gordon via swift-evolution wrote: >> One initial bit of feedback - I believe if you have existential types, I >> believe you can

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

> 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-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] [Pitch] Parse expressions after 'as' and 'is' instead of just types

+1 Seems like it could enable very powerful behaviour going forward > On 16 May 2016, at 23:06, Joe Groff via swift-evolution > wrote: > > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd > expect, but does lead to problems when an 'as'

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

uence has typealias Element, does that mean I also >>>>> have MyConformingSequence.Element? >>>>> >>>>> If so, I think there is a potential impact on existing code not >>>>> mentioned. Suppose MyConformingSequence already (unwi

Re: [swift-evolution] Union instead of Optional

Enums with associated types in Swift are the equivalent of unions, even if they don’t have the name. I don’t see what your proposal is trying to solve? > On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution > wrote: > > > It’s kind of same idea of TypeScipt 2,

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

Hi Karl, As author of this proposal, the one about constraints on associated types, and the one on type-aliases in protocols (all from the Generics Manifesto - original authorship to Douglas Gregor) I’d like to provide additional reasoning behind my wish to push this proposal through, as a

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Totally agree. It feels weird to have protocols decide on how "Self" conformance a are inherited. It should a decision for the conforming type. > On 13 May 2016, at 04:21, Joe Groff via swift-evolution > wrote: > > >> On May 12, 2016, at 5:49 PM, Matthew Johnson

Re: [swift-evolution] SE-0084 spinoff: Newlines as item separators

to reintroduce commas would be? > The losing track of where the items are separated? > > Maybe there could be an Xcode key shortcut to toggle commas off and on for > newline separated items, like the current toggler for comments. > >> On 18 May 2016, at 6:28 PM, David Hart via

Re: [swift-evolution] SE-0084 spinoff: Newlines as item separators

-1 I see one big downside. Contrary to statements, which rarely appear on the same line, other list elements are more frequently reformatted, from one line to multiple lines and back. For example, I'll try to find function declarations with too many arguments (formatted on multiple lines) and

Re: [swift-evolution] SE-0084 spinoff: Newlines as item separators

Could you show me an example of a fictional EDSL that gets better with newline separated lists? > On 18 May 2016, at 16:02, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > > On May 18, 2016, at 8:08 AM, David Hart via swift-evolution &

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-0088: Modernize libdispatch for Swift 3 naming conventions

+1 I’d also vote for dispatchAsync and dispatchSync. For reference, c# is also a language with fairly verbose conventions like Swift and it has adopted the Async convention for their “async” methods. > On 11 May 2016, at 20:08, Darren Mo via swift-evolution > wrote:

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] 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

  1   2   3   4   5   6   >