Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

Can we provide a 'standard' method/function that can be used to combine ordered hash values (`[Int] -> Int`)? That could make manually implementing `hashValue` less burdensome. TJ On Fri, Dec 15, 2017 at 12:08 PM, Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > > > On

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

+1 from me. I have, all along, wished that we could use the designated/convenience initializer patterns with structs. This moves us a little bit closer, at least. On Mon, Nov 27, 2017 at 11:05 AM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 27, 2017, at

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

I am all for this. are many types where there is an obvious 'zero' or 'default' value and the ability to express "use that when possible" without an overload is welcome. The best thing that I can think of right now, in terms of syntax, is actually using @overload ``` struct ResourceDescription

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

I used the existence of the first one in my explanation of explain optionals. "There is a reasonable default value for an optional type. 'nothing'." TJ On Mon, Nov 6, 2017 at 6:52 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 6, 2017, at 4:29 PM, Kelvin

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

+1 from me… for what it's worth. The value, in my opinion, is that we won't each have to add result. I would prefer Either but I will take Result. On Thu, Nov 2, 2017 at 2:35 PM, Dave DeLong via swift-evolution < swift-evolution@swift.org> wrote: > > On Nov 2, 2017, at 12:32 PM, Jon Shier

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

* What is your evaluation of the proposal? + 1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes * Does this proposal fit well with the feel and direction of Swift? Yes, so long as we actually consider whether or not we want to allow these keywords eventually.

Re: [swift-evolution] Figuring out what you get for free

I guess the question is, "Do we want this to be the process we expect of and explain to newcomers?" On Sun, Sep 17, 2017 at 7:32 PM, Michel Fortin via swift-evolution < swift-evolution@swift.org> wrote: > Le 17 sept. 2017 à 18:00, Félix Cloutier via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

I wasn't arguing for a strictly parallel syntax. I was arguing against being able to omit labels. I don't view those as strictly tied together. How are they? On Mon, Sep 4, 2017 at 12:38 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > On Sep 4, 2017, at 10:52 AM, T.J. Usiy

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

While re-litigating has it's issues, I am for simplifying the rule and always requiring the labels if they exist. This is similar to the change around external labels. Yes, it is slightly less convenient, but it removes a difficult to motivate caveat for beginners. On Sun, Sep 3, 2017 at 4:35 PM,

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

A thousand times yes to this. On Tue, Aug 1, 2017 at 9:35 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift wrote: > >> >> >> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu wrote: >> >>>

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

+1 Maintaining parity between single and multi line strings is nice even though breaking scope is a strong argument against actually using this with single line literals. On Wed, Jul 12, 2017 at 7:15 PM, Timothy Wood via swift-evolution < swift-evolution@swift.org> wrote: > > +1 This seems

Re: [swift-evolution] [Pitch] Object aliases

This video is a nice introduction to why lenses are. It is in Haskell, yes, but I believe that you can infer everything that you need from the context provided. A Brief Introduction of the Haskell Lens Library On Wed, Jun 28, 2017 at 1:42 PM, Daryle

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

+1 I only gave it a quick read though. On Sun, Jun 11, 2017 at 3:01 PM, Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote: > 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

Re: [swift-evolution] Type Safe Key-Value Construct

Wouldn't a struct be the better answer here overall or (with slightly fewer assurances) using an enum as the `Value` type? On Sat, Jun 10, 2017 at 12:56 PM, David Moore via swift-evolution < swift-evolution@swift.org> wrote: > > Hello swift-evolution, > > There are clearly weaknesses with

Re: [swift-evolution] History and future of Swift's parentheses

I vote language complexity in the form of hygienic macros. /me slinks away On Sat, Jun 10, 2017 at 1:25 AM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun 9, 2017, at 2:42 PM, Gor Gyolchanyan via swift-evolution < > swift-evolution@swift.org> wrote: > > > > My

Re: [swift-evolution] Revisiting SE-0110

I, for one, would be willing to accept Xiaodi's suggestion involving `let`–especially if (pipe dream follows) we could use the same syntax in functions/methods to destructure parameters. On Thu, Jun 1, 2017 at 3:32 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On

Re: [swift-evolution] VisualFoundation Framework

I would like to emphasize how much I would appreciate a standard type such as this ``` public enum OriginLocation { case lowerLeft case upperLeft #if os(OSX) public static let defaultPlatformLocation: OriginLocation = .lowerLeft #endif #if os(iOS) public static let

Re: [swift-evolution] VisualFoundation Framework

Bezier Paths, CGPoint, CGFloat, CGRect, and something to represent the origin location would be nice. On Wed, May 31, 2017 at 10:48 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Hi Everyone, > > I am not sure whether Swift Evolution’s charter extends to the common >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

Is there any mechanism to mark a property as not participating in derived conformances? One instance might be that I have a memoization/cache related property that is stored but should not be considered when equating two instances. TJ On Tue, May 16, 2017 at 3:51 AM, Xiaodi Wu via

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

NSNumber is immutable, you get the value semantics anyway... > > On May 15, 2017, at 1:09 PM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > My understanding of the reasoning is that `NSNumber` is an object in > Objective-C and not a struct

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

My understanding of the reasoning is that `NSNumber` is an object in Objective-C and not a struct. There is already one level of decision when translating to objc in that regard. Switching between reference semantics/class and value semantics because of optionality is surprising. On Mon, May 15,

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

+1 overall. Is there any hope for a diagnostic to call violations of the issue outlined in the following passage out? any passing of self into an API that takes a concrete String will need to > be rewritten as String(self). If Self is a String then this should > effectively optimize to a no-op,

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

- What is your evaluation of the proposal? +1 - Is the problem being addressed significant enough to warrant a change to Swift?Yes - Does this proposal fit well with the feel and direction of Swift?I think so. - If you have used other languages or libraries with a similar feature, how do you feel

Re: [swift-evolution] [Review] SE-0175 Package Manager Revised Dependency Resolution

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to the Swift Package Manager? Yes, pinning was fairly confusing to reason about * Does this proposal fit well with the feel and direction of Swift? I think so. * If you have

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

``` let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0) let y: (a: Int, r: Int, g: Int, b: Int) = x print(y.a) // currently, prints "0" ``` ^^I would like for this not to be possible. That is not at all what I expect or–even now that I see what is happening–desire in any way. TJ On

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

Xi: "Does this gain something by being part of the standard library?" Me: "This gains discoverability and standardization by being part of the standard library." Xi: "By definition, if it's in the standard library, it becomes standardized and discoverable." We're in agreement, then? Repeating a

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

This gains discoverability and standardization by being part of the standard library. New folks would not have to import some library or roll their own to get this reasonable to expect/hope or hope for functionality. Perhaps removing the old function isn't going to work but repeating collections

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

I think that `Either` in the standard library with some means to provide generalized behavior for two-cased enums would be an amazing salve for this. Handling errors thrown in Playgrounds is one of the best examples, in my opinion, of why we need something like Either/Result in the standard

Re: [swift-evolution] [Review] SE-0174: Change `filter` to return an associated type

+1 There are many things that I would like more but this is a reasonable compromise. On Mon, May 1, 2017 at 8:02 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > Another possibility is to make “map” generic on the return type, something > like: > >

Re: [swift-evolution] [Pitch] Enum with generic cases

/me Pushes implementation detail related concerns out of head +1 I want this feature but I seriously doubt that it is feasible at the moment. There are so many 'more pressing' features that, even if this were accepted now, it wouldn't be implemented it in time for Swift 4. That said, I would

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

- What is your evaluation of the proposal? + 1 - Is the problem being addressed significant enough to warrant a change to Swift? Yes - Does this proposal fit well with the feel and direction of Swift? I'm not completely sure. - If you have used other languages or libraries

Re: [swift-evolution] SE-0171: Reduce with inout

+1 from me. I currently use reduce and just deal with the costs. On Fri, Apr 14, 2017 at 10:15 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 14, 2017, at 9:05 PM, David Sweeris wrote: > > > > > >> On Apr 14, 2017, at 15:33, Matthew

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

+1 with the clarifications provided in the thread. On Sun, Apr 9, 2017 at 4:44 AM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > Review of SE-0168 "Multi-Line String Literals" > > • What is your evaluation of the proposal? > > Yes good idea. Though I am not clear as to

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

+1 One less level to explain and not much lost in the shuffle. On Mon, Mar 20, 2017 at 8:44 PM, Lucas Neiva via swift-evolution < swift-evolution@swift.org> wrote: > I think it's worth simplifying the access levels by removing > `fileprivate`. Changing `private` to cover the common file-level

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

This does work and can be the solution, I suppose, but I was thinking about agreeing upon some convention that could actually make it into the protocols or–at the least–documentation. As it is, the problem creeps up on newcomers and isn't so obvious until you actually have a second version of

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Is there any sense of encoding versions (as in, changes to the JSON representation, for instance?) I don't know that it is necessarily a good idea overall but now is the time to consider it. On Fri, Mar 17, 2017 at 2:27 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

Re: [swift-evolution] Infer types of default function parameters

-1 from me. I prefer explicitness at function boundaries. On Fri, Mar 10, 2017 at 4:55 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 10, 2017, at 1:40 PM, Kilian Koeltzsch via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi all, > > I sent the

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

+1 for the fix. Solid and straightforward. On Thu, Mar 9, 2017 at 9:32 AM, Rod Brown via swift-evolution < swift-evolution@swift.org> wrote: > There has been a lot of discussion around this design decision. > Personally, I’m with you: this should be allowed. Protocol extensions > should be

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

- What is your evaluation of the proposal? +1 - Is the problem being addressed significant enough to warrant a change to Swift? Yes. Yes. A thousand times, yes. - Does this proposal fit well with the feel and direction of Swift? Yes. - If you have used other languages or

Re: [swift-evolution] [Discussion] Simplifying case syntax

I support the first part, removing `case let` in a switch. I actually prefer one let out front in many ways but I have a much stronger preference for eliminating a 'style' choice that dramatically impacts the interpretation of the code. Binding each value is more explicit, so I am fine with it

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

What is your evaluation of the proposal? +1 Is the problem being addressed significant enough to warrant a change to Swift? Yes Does this proposal fit well with the feel and direction of Swift? Yes How much effort did you put into your review? A glance, a quick reading, or an

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Submodules will, I hope, afford us the ability to share meaningfully arranged API. In an ideal scenario, I could have a module that has all of the smaller pieces of 'utilities and conveniences' that one builds up broken into submodules. Importing one of the submodules from its enclosing module

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

+1 overall. prefer this approach over the "scope based" approach in the other proposal On Wed, Feb 22, 2017 at 10:10 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 21, 2017, at 11:54 PM, Robert Widmann > wrote: > > > On Feb 22,

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

+1 if this doesn't have terrible implications. The downside to making it IUO or Optional is that that changes the type signature of `index(i:offsetBy:)` for no reason other than a default value. If you decide to change to or away from providing a default value it probably shouldn't change the

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

What if, at least to begin with, we don't infer anything with regard to what is a subtype and what isn't? Clear diagnostics could be given when the compiler spots a potential conflict. I would also like to suggest that we think of a way to spell "any one of these cases" for closure

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

I'm going to update the draft with points addressed here and the twitter conversation. There have been quite a few implications to consider pointed out. This feature is not 'for' the compiler as much as it is for humans writing code, but I will address that in the update. On Sun, Feb 19, 2017 at

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

There shouldn't be a need for a third arrow with regard to purity. Impure encompasses pure in that there is simply no guarantee of purity with an impure function. You should be able to use a pure function in place of an impure function without any issue whatsoever. On Fri, Feb 17, 2017 at 1:35

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

Anton, It is my opinion that you are describing an entirely different, and somewhat orthogonal, feature. I would like the feature that you describe. Constant expressions are powerful and open up quite a few optimizations. What constexpr addresses is not purity, at the heart of it. Pure

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

nc’, the same way we put ‘mutating' in front of mutating > functions… it seems to me like these are part of the same family. > > I agree we should allow inout. > > Thanks, > Jon > > On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org

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

I held your opinion, although not terribly steadfast. Joe Groff convinced me that I was being pedantic with "'inout' is 'value goes in, value-prime goes out'" and the fact that it composes; you could use pure `+=` on a local value inside another pure function. The specific details of `inout` mean

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

Thank you everyone. Since there does some to be interest, I have created a gist with some updates based on feedback. I have only incorporated the quickly integratabtle bits, so far. https://gist.github.com/griotspeak/31445ddcdba44bb8de599be6c9a93bd1 On Thu, Feb 16, 2017 at 3:03 PM, Nicolas

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

# Pure Functions * Proposal: [SE-]( https://github.com/apple/swift-evolution/blob/master/proposals/-name.md) * Author(s): [TJ Usiyan](https://github.com/griotspeak) * Status: **Awaiting review** * Review manager: TBD ## Introduction Some functions are, essentially, only meant to be

Re: [swift-evolution] final + lazy + fileprivate modifiers

"Either keep it or drop it, but don't keep fiddling with it." sums up my position well. On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [Discussion] Variadics as an Attribute

+1 I don't see tuples as a better solution for this without substantial work. Even after all of that work, I am not convinced that tuples would be a better solution. On Wed, Feb 15, 2017 at 7:16 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > –1 for me, I’ll explain

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

+1 from me. I hope that operators get more work soon, especially with regard to math. On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > +1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as > operators. > > There was

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0150 Package Manager Support for branches

• What is your evaluation of the proposal? + 1 • Is the problem being addressed significant enough to warrant a change to Swift? Yes • Does this proposal fit well with the feel and direction of Swift? Yes • If you have used other languages or libraries with a similar

Re: [swift-evolution] protocol-oriented integers (take 2)

Oh, I misread the arrows in that diagram and this makes much more sense now. Thanks. On Fri, Jan 27, 2017 at 9:14 AM, Stephen Canon <sca...@apple.com> wrote: > The bitwise stuff isn't on ArithMETic | ARITHmetic | Number | whatever. > > On Jan 27, 2017, at 9:13 AM, T.J. U

Re: [swift-evolution] protocol-oriented integers (take 2)

Regarding `Number` or `Numeric`: Does everything in Arithmetic apply to complex numbers and do we want it to? The bitwise stuff is where I think that there might be a mismatch. On Thu, Jan 26, 2017 at 2:26 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun Jan

Re: [swift-evolution] Default Generic Arguments

I like this approach as a first pass. It leaves room for other, more forgiving strategies later and is relatively easy to explain. On Tue, Jan 24, 2017 at 4:16 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 24, 2017, at 11:41, Alexis via swift-evolution < >

Re: [swift-evolution] Default Generic Arguments

ave every > argument defaulted. If someone can’t give a real-world example, I would > require empty angle brackets just to differentiate defaulted vs inferred > arguments. > > -DW > > On Jan 23, 2017, at 12:25 PM, T.J. Usiyan via swift-evolution < > swift-evolution@swif

Re: [swift-evolution] Default Generic Arguments

I am against requiring empty angle brackets. I could live with it either way, but I think that one reason to provide default types is to hide the detail that there is a type parameter until such a time as it is needed. Empty angle brackets call attention to the feature in a manner that discards

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Implementing equality would be made tedious again if we lose this. ``` enum Jams : Equatable { case dmsr(Bool) case kiss(Bool, Bool) case pheromone(Int, Bool, Int) public static func ==(lhs:Jams, rhs:Jams) -> Bool { switch (lhs, rhs) { case let (.dmsr(left),

Re: [swift-evolution] Reduce with inout

Is there any chance that the forthcoming memory annotations could help here? If we had some way to signify that the item returned from each call to the closure should be connected to the incoming argument… On Sat, Jan 21, 2017 at 2:27 AM, Charles Srstka via swift-evolution <

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0148 Generic Subscripts

+1 for the proposal and default arguments on subscripts On Thu, Jan 19, 2017 at 11:16 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 19, 2017, at 15:39, Douglas Gregor wrote: > > Hello Swift community, > > The review of SE-0148 “Generic

Re: [swift-evolution] Reduce with inout

`reduceInout` On Tue, Jan 17, 2017 at 6:30 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Agree. The functional style should keep the functional name. > > On Tue, Jan 17, 2017 at 16:18 David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Jan

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

+1 to all of that. The proposal in general and the import rule. On Tue, Jan 17, 2017 at 7:07 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Nov 5, 2016, at 2:44 AM, Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > > On 2 Nov 2016, at 20:54,

Re: [swift-evolution] Allow ' in variable/constant names?

Please yes, if reasonably possible. I can see how it might not be though. On Wed, Jan 11, 2017 at 7:46 PM, Jay Abbott via swift-evolution < swift-evolution@swift.org> wrote: > As Rob Mayoff pointed out, you can use MODIFIER LETTER PRIME - or PRIME, > DOUBLE PRIME, and TRIPLE PRIME - which makes

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1 from me. It doesn't really pay for itself. On Sun, Jan 8, 2017 at 2:26 PM, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > *if let *is fine the way it currently is. It may be strange to newcomers > since it is unique, but once you get used to it, it is super useful. > >

Re: [swift-evolution] Move placement of 'throws' statement

I don't know how this became a discussion for specifying errors when throwing but +1 on the off chance that this thread is actually used to gauge interest. On Tue, Dec 27, 2016 at 10:27 PM, Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > -1 for checked exceptions. Don't

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

-1 from me. On Thu, Dec 8, 2016 at 7:39 AM, Jim Malak via swift-evolution < swift-evolution@swift.org> wrote: > Ok, thanks > > - Jim > -- > *From:* Adrian Zubarev > *Sent:* Thursday, December 8, 2016 7:38:22 AM > *To:* Jim Malak >

Re: [swift-evolution] [swift-build-dev] [swift-evolution-announce] [Review] SE-0145: Package Manager Version Pinning (Revised)

+1 Overall. I am not in favor of automatic pinning being the default behavior but it isn't such a big issue. On Fri, Dec 2, 2016 at 12:18 PM, Anders Bertelrud via swift-evolution < swift-evolution@swift.org> wrote: > On 2016-11-28, at 09.44, David Sweeris via swift-build-dev < >

Re: [swift-evolution] [Review extended] SE-0143: Conditional Conformances

+1 on the revised version. I agree with the conservative approach of disallowing overlapping/multiple conformance with plans to consider expanding behavior later. On Wed, Nov 9, 2016 at 7:03 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > During the first round of review

Re: [swift-evolution] [Proposal] Type Narrowing

I am mostly opposed because I don't see how this could avoid being complicated to explain compiler magic. Making this accessible as a feature for our types and operations would be a challenge and doesn't look to have a worthwhile yield for the effort. We can accomplish most, if not all, of this

Re: [swift-evolution] [Pitch] Non-class type requirements on protocols (eg : struct, : enum)

I would like the ability to specify that something is an enum so that I could model a generic `Result` type. ``` protocol Result : enum { associatedtype Payload case success(Payload) case failure(Error) } ``` the basic idea being that I could then, while conforming, state which cases

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

I want this feature. Both class in protocol and protocol in class could clean up many relationships but I think that a blocking concern is "How does this interact with generics?" Nesting types in generic types is already disallowed and how different is this feature from that? On Mon, Oct 17, 2016

Re: [swift-evolution] stored properties in extensions (was: associated objects)

How much would convenient method forwarding when wrapping change how desirable this feature is? I am hesitant to add storage to already allocated instances if we can avoid it. On Sun, Oct 16, 2016 at 5:02 PM, Jay Abbott via swift-evolution < swift-evolution@swift.org> wrote: > Greg: > > I've

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

I don't like this at all and it comes down to "what is hidden can also be unhidden". This, to me, feels like it would create more confusion than it would address. Why not just use `internal` for `hidden` items? If we're ok with modifying import statements, why not simply have a command that

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

+1 from me. Seems like a solid change. On Wed, Oct 12, 2016 at 12:39 AM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > +1. Haven't hit this issue personally, but I agree it's important and the > proposed solution seems like the right fix. > > On Tue, Oct 11, 2016

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

Painful +1. I use the first one a whole lot in a project and it is going to get ugly. That said… I can see how it is tricky in a way that doesn't really pay off for most people. Removing the first feature might even be necessary for what I hope will ease the ugly. I don't see "Default generic

Re: [swift-evolution] private & fileprivate

While I agree that private/fileprivate didn't change much… I have to say that I wish we had simply kept private as is and ended up with private, internal, public, and open. It is more tricky to explain than it is worth. TJ On Fri, Oct 7, 2016 at 6:56 PM, Jordan Rose via swift-evolution <

Re: [swift-evolution] Propagating Optionals

On Sun, Sep 25, 2016 at 4:19 PM, Trans via swift-evolution < swift-evolution@swift.org> wrote: > As I've been learning Swift recently, one aspect of the language > jumped out at me with a "code smell". Namely, the way Optionals are > handled. For starters, just consider how long this chapter is:

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

I noticed this immediately and assumed that it was recognized as suboptimal but tolerable for now. The required underscores were meant to leave space for improvement in this regard, no? If not… sad face. TJ On Tue, Oct 4, 2016 at 12:21 PM, Erica Sadun via swift-evolution <

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0143: Conditional Conformances

What is your evaluation of the proposal? +1 with concern about the least specialized implementation winning. I think that this could be tricky to explain or build an intuition around. Is the problem being addressed significant enough to warrant a change to Swift? Yes Does this proposal fit

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0141: Availability by Swift version

What is your evaluation of the proposal? +1 Is the problem being addressed significant enough to warrant a change to Swift? Yes Does this proposal fit well with the feel and direction of Swift? Yes If you have used other languages or libraries with a similar feature, how do you feel

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

What is your evaluation of the proposal? +1 Is the problem being addressed significant enough to warrant a change to Swift? Yes. A thousand times yes. Does this proposal fit well with the feel and direction of Swift? Yes. If you have used other languages or libraries with a similar

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

I… like this syntax but I have to admit that I am confused about ```protocol IntSequence : Sequence where Iterator.Element == Int { ... } ``` I think that this example needs a better subtype/subprotocol to motivate the feature. This particular type seems more like a constrained typealias

Re: [swift-evolution] Tuples as NominalTypes

Hello Muhammad, I am not exactly sure what you are after with this or your previous post about tuples. Tuples are 'type safe' for any definition of 'type safety' that I can summon. Switching over tuples to restructure them is, in my opinion, a main source of the type safety provided in tuples. I

Re: [swift-evolution] Class scoped access level

I am firmly against this. The 5 levels that we have cover us well and have enough complexity already. On Sat, Sep 10, 2016 at 5:23 AM, Tom Bates via swift-evolution < swift-evolution@swift.org> wrote: > I agree that classprivate would probably not work, maybe constructprivate? > but then you are

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0139: Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

+1 I like this especially considering that 64 bit iOS has led to more boxing to `NSNumber` for convenience On Fri, Sep 2, 2016 at 1:23 PM, Scott James Remnant via swift-evolution < swift-evolution@swift.org> wrote: >  > > Makes ObjC APIs even easier to work with, without any cost to working

Re: [swift-evolution] Swift Package Manager 3.0 Project Status

What are the near term plans–if there are any–for supporting iOS? I made the mistake of assuming support was a couple months away at most when the package manager was announced. I plan to port my iOS/Mac frameworks over as soon as I can. TJ On Wed, Aug 17, 2016 at 6:44 PM, Daniel Dunbar via

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

These are a couple comments from Chris Lattner that come to mind "FWIW, this has been discussed before on swift-evolution. Adding them isn’t out of the question, but it is a lot more complicated than it looks for the type checker." "Here is my concern: Swift enums should be good enough that we

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

+1 from me. I followed the discussion and read the proposal. It seems like a fairly straightforward solution to the problem. On Sun, Aug 7, 2016 at 9:03 PM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > > > * What is your evaluation of the proposal? > > +1 > > Although if

Re: [swift-evolution] [Review] SE-0129: Package Manager Test Naming Conventions

* What is your evaluation of the proposal? + 1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes * Does this proposal fit well with the feel and direction of Swift? Yes * If you have used other languages or libraries with a

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

* What is your evaluation of the proposal? +1 for the first design listed. Simplicity is nice but the ability to vend non-final classes that cannot be publicly subclassed is worth the complexity. * Is the problem being addressed significant enough to warrant a change to Swift? Yes.

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

I am ok with moving the public requirement for sealed-by-default. I have one qualm though. This would actually make starting out with the language a suboptimal experience. As (before, really) I teach what subclassing is, I have to explain this keyword to make subclassing possible. That sounds good

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

On Tue, Jul 19, 2016 at 6:26 PM, Peter Livesey via swift-evolution < swift-evolution@swift.org> wrote: > I'm new to this thread, but I've read every email so far. There are a few > things I find confusing with the proposal, so I'll try to sum up what I see > so far: > > 1. I don't understand what

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

Haskell has much more than import everything and import itemized. https://wiki.haskell.org/Import Hiding is important for avoiding collisions of name and/or function. On Mon, Jul 18, 2016 at 9:19 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > Our import story definitely

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

What about using duplicate declarations to indicate that two files are part of the same module? On Mon, Jul 18, 2016 at 8:33 PM, Robert Widmann wrote: > > > On Jul 18, 2016, at 5:26 PM, Brent Royal-Gordon > wrote: > > > >> On Jul 18, 2016, at 4:50

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

> > > Modules names are tied to a directory structure that describes their > location relative to the current module and it will now be an error to > violate this rule. For example: > > > > module String // lives in ./String.swift > > > > module String.Core // lives in ./String/Core.swift > > > >

Re: [swift-evolution] Nested for-in loops syntax

re: cross (nod to Dave Abrahams for the clean implementation) /// 'Cartesian product' of two sequences public func cartesianProduct(lhs:Left, rhs:Right) -> [(Left.Iterator.Element, Right.Iterator.Element)] { return lhs.flatMap { x in rhs.map { (x, $0) } } } On Sun, Jul 17, 2016 at 11:54 AM,

  1   2   >