Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

one > > On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > Yes, sorry, my point was that this consideration isn't spelled out. > > Another question is whether or not making a subclass of an open class >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

, 2016 at 10:32 AM, Karl <razie...@gmail.com> wrote: > > > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > > > What happens if I want an `internal` subclass of an `open` class? > > That should be allowable. Y

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

What happens if I want an `internal` subclass of an `open` class? On Sat, Jul 16, 2016 at 10:09 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Swift has always gone towards making declarations explicit to read. Having > open on thé class declaration makes it so you

Re: [swift-evolution] [Review #2] SE-0091: Improving operator requirements 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 * If you have used other languages or libraries with a similar

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

+1 from me. I share similar concerns about 'easily' allowing subclassing within the module and testability but I am completely for this idea. On Wed, Jul 6, 2016 at 8:33 AM, James Campbell via swift-evolution < swift-evolution@swift.org> wrote: > -0.5 I think preventing subclassing is a bad

Re: [swift-evolution] [Pitch] Self.withoutSpecialization

by hook or crook failed, but I won't let that get me down. No. No I won't. On Sat, Jul 2, 2016 at 11:40 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > > on Fri Jul 01 2016, "T.J. Usiyan via swift-evolution" < > swift-evolution@swift.org>

Re: [swift-evolution] [Proposal] Sealed classes by default

+1 to sealed +1 to sealed-as-default. I prefer the need to explicitly share details that I would like to share. Separately, I do think that we need to improve the tools for auditing and organizing APIs. On Sat, Jul 2, 2016 at 8:35 AM, L. Mihalkovic via swift-evolution <

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

+1 from me I think that it makes sense since there exists now a possibility for Obj-C types to come in as types with value semantics. TJ On Fri, Jul 1, 2016 at 7:37 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone. After implementing SE-0072, disabling the

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

+1 if SE-0111 is accepted. 0 otherwise. On Fri, Jul 1, 2016 at 7:34 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On 02.07.2016 1:49, Daniel Duan via swift-evolution wrote: > >> Chris Lattner via swift-evolution writes: >> >> I think there's an

Re: [swift-evolution] [Pitch] Self.withoutSpecialization

Bump On Fri, Jul 1, 2016 at 11:56 AM, T.J. Usiyan wrote: > > > ## The Issue > Given > ``` swift > public protocol Zipper1D : CustomStringConvertible { > associatedtype Element > } > ``` > > We can almost write a `flatMap` which keeps the general identity of self > and

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

* What is your evaluation of the proposal? a reluctant +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

[swift-evolution] [Pitch] Self.withoutSpecialization

## The Issue Given ``` swift public protocol Zipper1D : CustomStringConvertible { associatedtype Element } ``` We can almost write a `flatMap` which keeps the general identity of self and swaps out the Element in the output. ``` swift func flatMap< NewElement, SegmentOfResult :

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

* What is your evaluation of the proposal? + 1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes. When inference goes wrong it is frustrating and difficult to puzzle out. * Does this proposal fit well with the feel and direction of Swift?

Re: [swift-evolution] modifying Array to return Element! when subscripted

What about an additional method? No subscripting, just a method that throws instead of trapping? On Tue, Jun 28, 2016 at 2:08 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Thu Jun 23 2016, "L. Mihalkovic via swift-evolution" < > swift-evolution@swift.org>

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

what about `*LiteralRepresentable`? On Sun, Jun 26, 2016 at 11:11 AM, Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote: > Syntax by itself is not clear enough. Appending Initializable makes it too > long. > > We can replace Syntax with LiteralSyntax to clarify. Then we will

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

I think that we should change it to `if. Inline filtering is useful, even if it isn't used much at present but the inconsistency doesn't help adoption. On Fri, Jun 24, 2016 at 11:06 AM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > I’ll share some of mine from a single

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

If we chose something other than strongerThan and weakerThan, I would really like to see something like evaluateBefore, evaluateAfter foundBefore, foundAfter lookupBefore, lookupAfter On Thu, Jun 23, 2016 at 11:32 AM, Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > Ross

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

Karl - Absolute value of `Int.min` is currently not representable by an Int. On Wed, Jun 22, 2016 at 9:32 PM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > Looks very good. A couple of points: > > - I’m not convinced about ‘absoluteValue’, with an associated type. I >

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

plx: wouldn't the same overload resolution strategy be appropriate here? "most specific choice, otherwise diagnostic" separately: Are there any subscripts in the standard library that would be throwing/generic but can't be? On Wed, Jun 22, 2016 at 9:13 AM, plx via swift-evolution <

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

Thinking on it more after that–admittedly–visceral reaction, the proposed changes would be an annoying break from the terms but would remain as discoverable via autocomplete and can still be found easily when searching. I'd like to amend my vote to 0. If it makes the methods/functions easier to

Re: [swift-evolution] Arbitrary-sized integers

There is also a fairly robust implementation of arbitrary size integers here https://github.com/lorentey/BigInt/tree/master/Sources On Tue, Jun 14, 2016 at 10:02 PM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > 128-bit Ints have been discussed here a few weeks ago: >

Re: [swift-evolution] [Discussion] Default Closure Arguments

What would this help you express? It is fairly difficult to read the type and understand your motivation from this reduced example. It is clear what you want but not what it wins you or us. On Tue, Jun 14, 2016 at 3:40 AM, Andrew Bennett via swift-evolution < swift-evolution@swift.org> wrote: >

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

I will be in San Francisco during WWDC as well. On Mon, Jun 6, 2016 at 12:03 PM, Michael Sheaver via swift-evolution < swift-evolution@swift.org> wrote: > I am attending WWDC and would love to attend this proposed meetup - if you > all can tolerate a Swift baby who is just learning to crawl! :)

Re: [swift-evolution] [Proposal] Enum subsets

relationships means so > it may very well be a better solution. It certainly sounds like a more > general solution but I am not convinced that that is an advantage when > trying to deal with a strict subset. > > TJ > On Sat, Jun 4, 2016 at 1:25 AM, Chris Lattner <clatt...@apple.com>

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

*please* let us not repeat the mostly avoidable challenging-to-explain-to-newcomers-and-vetarans-alike situation that we had in Obj-C with regard to `nil`. nil Nil NULL NSNull nullptr kCFNull __DARWIN_NULL are the representations of 'don't have' that come to mind. On Sun, Jun 5, 2016 at 2:39

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

+1 I think that it is an improvement overall and the work for consistency is appreciated. On Sat, Jun 4, 2016 at 10:03 PM, Greg Titus via swift-evolution < swift-evolution@swift.org> wrote: > > I think that Jon has exactly described my view on this proposal. Thanks, > Jon. > > -1. > > -- Greg

Re: [swift-evolution] [Proposal] Enum subsets

, Chris Lattner <clatt...@apple.com> wrote: > > On Jun 3, 2016, at 2:35 PM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > Since this seems to have some interest, I've made a gist. > > https://gist.github.com/griotspeak/963bc87a0c244

Re: [swift-evolution] [Proposal] Enum subsets

h on 'self', would those > members be available to the child automatically? > - What happens if you have two (or more) slices with disjoint members? > (e.g. 'LCDColors' and 'TrafficLightColors') Would they be considered > completely separate 'sub-types'? > > Best, > Austin > >

Re: [swift-evolution] [Proposal] Enum subsets

en > would allow: > > > ``` > enum AppErrors { > // Defined by its subsets > case NetworkingErrorBase = 1000 > case UIErrorBase = 2000 > } > > enum NetworkingErrors subset: AppErrors { > case NWError1 = NetworkingErrorBase, NWError2. NWError3 > } > > enum

Re: [swift-evolution] [Proposal] Enum subsets

olors { > subset LCDColors red, green, blue > } > ``` > > On Jun 3, 2016, at 7:22 AM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > This is loosely related to but not meant to 'compete' with the ad hoc enum > proposal. > > ## Introduction >

[swift-evolution] [Proposal] Enum subsets

This is loosely related to but not meant to 'compete' with the ad hoc enum proposal. ## Introduction This proposal adds/creates syntax to allow ad hoc creation of enums whose members are strict subsets of explicitly defined enums. Swift-evolution thread: [Discussion thread topic for that

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

+1 It has nagged at me that this can happen even though I understood *why* it happens. On Thu, Jun 2, 2016 at 6:22 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 2, 2016, at 2:43 PM, Brent Royal-Gordon > wrote: > >> In my opinion,

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

• What is your evaluation of the proposal? +1 • Is the problem being addressed significant enough to warrant a change to Swift? Yes. I have often been frustrated by needing to break up conditions to make complex checks. I am not completely sure that this proposal addresses that issue but it is

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

by the developer. On Thu, May 26, 2016 at 11:20 AM, L. Mihalkovic < laurent.mihalko...@gmail.com> wrote: > what i care about is to have a choice about what DEFINES the identity of > my values, not just an all-or-nothing situation. > > On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-e

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

+1 to a `deriving` keyword On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > Can we just copy the solution from Haskell instead of creating our > own? It's just better in every aspect. Deriving `Equatable` and `Hashable` > would become >

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

t/blob/master/docs/GenericsManifesto.md ("Generic > Protocols"). > > On May 25, 2016, at 8:43 PM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > +1 for the proposal. > > Another quirk of associated types is that they cannot be overloaded as far

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

+1 for the proposal. Another quirk of associated types is that they cannot be overloaded as far as I can tell. Requiring explicit declaration could move us toward allowing multiple types to serve. Does anyone else see this as a useful feature to pursue? TJ On Wed, May 25, 2016 at 6:33 PM, Sean

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

+1 On Wed, May 25, 2016 at 7:50 PM, Patrick Smith via swift-evolution < swift-evolution@swift.org> wrote: > Sounds good to me. So it matches the order of the generic parameters? > > e.g. > > func foo(t: T, u: U) { … } > > let f1 = foo > > So if the function declaration was

Re: [swift-evolution] [Proposal] Add property for negation to Bool

`var isFalse: Bool` seems like a nice resolution to me. no need for new keywords and it reads better than !foo On Sun, May 22, 2016 at 3:28 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > I think this would make more sense if we were to get more characters in > operators,

Re: [swift-evolution] [Discussion] Namespaces

+1 for namespaces. On Fri, May 20, 2016 at 10:52 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > > On 20 May 2016, at 14:51, Krystof Vasa via swift-evolution < > swift-evolution@swift.org> wrote: > > > > When you have namespaces Car and Animal and each contains a class

Re: [swift-evolution] Pitch: Modify the meaning of IBOutlet to remove the ! from the type

The attribute wouldn't change the behavior. The reference is still implicitly unwrapped. IB Outlets are, at least currently, IUO by necessity. I think that this proposal looks to make it less redundant. I didn't fully spot the use of `let` on the first or second reading but there is another

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

+1 converting to a string is definitely lossy for most cases. On Wed, May 18, 2016 at 12:09 AM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > * What is your evaluation of the proposal? >> > > +1, because: > - I believe the default/generic "printing"

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

+1 'default' alone makes this worth it. On Tue, Apr 26, 2016 at 5:28 PM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > +1 > I think it's a good thing. I don't think that it would introduce any bad > ambiguities for the human reader. E.g. "case .default:" may look

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

I've been thinking about the "conversion to some other type from this protocol" case for a while since it often seems to go against the guidance to add a property for this conversion. `Convertible` is always an awkward Protocol to write, in my opinion. Is there a chance that we simplify the the

Re: [swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

Could we reconsider rejecting the uppercase and lowercase conventions as a syntactic requirement? While I still disagree with enum cases not being UpperCamelCase, that decision narrows the 'approved' enough that the syntactic requirement would line up with guidance. It would also make teaching the

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes. Definitely. Operator overloading is currently fine in only the simplest of cases. * Does this proposal fit well with the feel and direction

Re: [swift-evolution] Idea: Named extensions

I have wanted this feature and floated it a while back. I hope we can get some traction this time but I doubt it will happen soon since additive features are tabled for a time. On Mon, May 16, 2016 at 3:47 PM, Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote: > I think

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

* 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] [Review] SE-0073: Marking closures as executing exactly once

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to Swift? I believe so. * 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] SE-0066: Standardize function type argument syntax to require parentheses

- What is your evaluation of the proposal? I don't like it but +1. The possible ambiguity is somewhat compelling. I actually think that, if this is accepted, it should be applied to closures as well. - Is the problem being addressed significant enough to warrant a change to Swift? I

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

+1 I have wanted this since the first beta. I hadn't proposed because I haven't come up with a nice syntax to do this in functions/methods. I don't particularly like func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String)) and the closes that I have come is to simply reuse the

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Something about your first paragraph reminded me of a question I've had for a while. Is there a reasoning behind not being able to restrict a protocol to value types? One way that this might be workable is if we could overload protocols for Value vs for reference. TJ On Tue, May 3, 2016 at 11:02

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

* 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] [Pitch] Reducing the bridging magic in dynamic casts

+1 to this. `as` is a hairy beast. On Mon, May 2, 2016 at 8:45 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On May 2, 2016, at 4:48 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > > > On May 2, 2016, at 3:45 PM, Chris Lattner via

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I agree that a keyword indicating intent would be nice, but I can't get behind override if what you're doing is providing your own implementation. I understand that we are trying to avoid adding keywords but could `implement` or a synonym work? If you override something that your superclass

Re: [swift-evolution] [Bug?] Reference types and mutating methods

The problem here seems to be with using the default implementation provided. If you override `append` in ObservedArray, the compiler allows it. That seems 'safe' but odd at first. I wouldn't *want* to implement every mutating method, but that is the current solution. I haven't puzzled out the

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

The benefit, as I see it, to this approach is not that it reduces noise. It is that it standardizes the naming decision in a broadly applicable manner. Look at the discussion that took place around `union` and `formUnion` to see that this standardization could be beneficial. The argument that this

Re: [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3

+1 from me On Tue, Apr 19, 2016 at 8:42 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > +1 from me; I’ve been dealing with a lot of conversion and yet it’s still > pretty confusing largely because of the implicit conversions, it also goes > against (pure) Swift’s elegant

Re: [swift-evolution] [Suggestion] Case-based dispatch for enum methods

I missed it the first time around. I like this idea but worry that it will invite some difficult to follow implementations. I think that there would need to exist some restrictions on how methods could be broken up. One such restriction might be that these implementations could not be broken up

Re: [swift-evolution] My personal beef with leading-dot syntax

*like* types. I, at no point, said that they are types. Pointing out what they can't do is not a great stance, in my opinion, because some of those things are perfectly reasonable but simply might not have been considered or attempted yet. I am *not* arguing that they are types. I am arguing that

Re: [swift-evolution] My personal beef with leading-dot syntax

com> wrote: > > > On Apr 4, 2016, at 6:27 PM, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Is a solution to this actually making the leading dot mean enum lookup, > full stop and allowing `Self.foo`? The case that that doesn't co

Re: [swift-evolution] My personal beef with leading-dot syntax

Is a solution to this actually making the leading dot mean enum lookup, full stop and allowing `Self.foo`? The case that that doesn't cover is static members on a type other than `Self`. I use it to great effect for standard instances of types, so I would appreciate *some* facility to provide

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

+1 I use it but won't fight for it or miss it. On Thu, Mar 31, 2016 at 12:45 PM, Javier Soto via swift-evolution < swift-evolution@swift.org> wrote: > I have never taken advantage of this. In fact, I didn't know this was > possible until just now :) and I would've definitely found it confusing

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0049 Move @noescape and @autoclosure to be type attributes

- 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. In particular, @noescape fits much better as a type attribute - If you

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

-1 I hope that default implementations living in the protocol will address this. I would even prefer to move in 'the other direction' and have optional methods on protocols come into swift as default implementations. TJ On Sat, Apr 2, 2016 at 6:07 AM, Brent Royal-Gordon via swift-evolution <

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

public internal (fileprivate | interfile) private Either choice is fine with me On Thu, Mar 31, 2016 at 11:33 AM, Jesse Squires via swift-evolution < swift-evolution@swift.org> wrote: > I really like this. +1 for the following: > > public > internal > fileprivate > private > > -Jesse > > On

Re: [swift-evolution] SetAlgebra naming update

I think that this is a great improvement and is consistent enough to accept. `form` will take some getting used to. TJ On Thu, Mar 24, 2016 at 9:39 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > Just an update: > > The naming guidelines working group went back into

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

This feature removes the need, in specific cases, for wrapping a function in a struct 'just for' the ability to use generics. ```swift typealias Parser = String -> Output // can now, sometimes, replace struct Parser { let transform: String -> Output init(transform: String -> Output) {

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

I like it. Searchable and clear. > > public > moduleprivate > fileprivate > private > > … > What do you all think? > > -Chris > > > ___ > swift-evolution mailing list > swift-evolution@swift.org >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

+1 This is a great addition. I've hoped for it since 1.0. On Sat, Mar 19, 2016 at 9:45 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > • What is your evaluation of the proposal? > > > +1 > > • Is the problem being addressed significant enough to warrant a change

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

Please… *please* let this lie. I understand that it will likely cause some specific cases to become more difficult but, on balance, it was a simplifying change. The syntax that we do have is clearer to those unfamiliar with programming idioms from other languages and people *are* familiar with

[swift-evolution] [proposal] Tail Call recursion attributes

Hello all, Introduction Tail call optimization can be a powerful tool when implementing certain types of algorithms. Unfortunately, Tail call optimization cannot be consistently used in Swift code. Developers cannot be sure that opportunities for this particular optimization to be applied are,

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

On Wed, Jan 6, 2016 at 2:18 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > > I just spent a half hour last night debugging an issue that turned out to > be caused by something getting written to a property which I thought was > being written to a local variable, due

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

The proposed additions to Indexible only require Indices… I don't see how adding them is such a mistake. If we can gain these behaviors while only *requiring* that minimum interface… go for it. TJ On Mon, Jan 4, 2016 at 3:49 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

+1 from me. It is a solid change that addresses an oddity in the language. On Sun, Jan 3, 2016 at 7:27 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > I like this. > > On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello

Re: [swift-evolution] Proposal: Allow comparisons of arrays possibly containing nil

Does this work for now? func ==(lhs:[T?], rhs: [T?]) -> Bool { let zipped = Zip2Sequence(lhs, rhs) return zipped.reduce(true) { (old, tuple) in old && (tuple.0 == tuple.1) } } On Fri, Jan 1, 2016 at 12:32 PM, Amir Michail via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Do things get any better if we combine the proposed changes and remove the bare case? Begin function reference with some symbol (# here but it doesn't matter), only use back tics to disambiguate keywords (which lines up with their current use) and remove the unadorned case to avoid ambiguity.

Re: [swift-evolution] Beef up Imports

*import* Foo *using* (bar, Baz, qux, waldo *as* fred) // a "whitelist import" *import* Foo *hiding* (bar, Baz, qux, waldo *as* fred) // a "blacklist import" Is nice but `hiding… (waldo as fred)` is confusing. Am I hiding waldo? It is also strange to look in that list for things that I am

Re: [swift-evolution] Immutable Structures

> > > > I don’t understand why we need the `mutating` keyword in the first place. > Is it for readability? Right now the compiler knows when a function mutates > a property and forces us to write `mutating`. Couldn’t it just fail > compiling when try to call a mutation function but we’re not

[swift-evolution] Proposal Sketch: Bring flexible array members in as Array|UnsafeReference

MIDIMetaEvent and MIDIEventUserData are both examples of framework provided types which rely on flexible member arrays. Their last member is (officially) an array of UInt8 with 1 element. In practice, developers are meant to allocate enough space for an array of the necessary length along with the

Re: [swift-evolution] Proposal: A standard library Fraction type

Calculating precession time of two frequencies is an example. (consider displaying two waveforms) On Mon, Dec 7, 2015 at 5:43 PM, T.J. Usiyan wrote: > We seem to have become distracted with the whole Time Signature thing. > Time signatures themselves are not Rationals. I

Re: [swift-evolution] Proposal: Add .times method to Integer type

-1 from me. It is simple enough for an extension and provides little benefit as a standard library inclusion. On Sun, Dec 20, 2015 at 9:10 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > +1 to 5.times{stuff} from me. I much prefer library functions to language >

Re: [swift-evolution] RFC: Proposed rewrite of Unmanaged

Would `consumeReleased` work at all? It captures the 'don't use this again' aspect and 'release' without much extra. On Sat, Dec 19, 2015 at 7:45 PM, Rainer Brockerhoff via swift-evolution < swift-evolution@swift.org> wrote: > On 18/12/15 16:46 , swift-evolution-requ...@swift.org wrote: > >

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

Shouldn't `filter` accomplish that? On Fri, Dec 18, 2015 at 7:35 AM, Al Skipp <al_sk...@fastmail.fm> wrote: > On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote: > > With a Cartesian Product type [like this]( > ht

Re: [swift-evolution] higher kinded types vs Python's syntactic sugars

015, at 4:35 AM, Al Skipp via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> With a Cartesian Product type [like this]( >> h

<    1   2