[swift-evolution] [Pitch] Make try? + optional chain flattening work together

Greetings swift-evolution! There is currently a disconnect between optional chaining and try? when it comes to optional flattening: struct SomeType { func nonThrow() -> SomeType? { return self } func doThrow() throws -> SomeType? { return self } func nonOptional() throws ->

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

> On Apr 12, 2017, at 5:44 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Apr 12, 2017, at 11:44 AM, Russ Bishop via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> * Str

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

Doug, Would it be worth deferring this slightly since it relies on SE-0166? If changes are made to SE-0166 as a result of review it will necessarily impact this proposal. Russ Bishop > On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution > wrote: > >

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0166 "Swift Archival & Serialization" begins now and runs > through April 12, 2017. The proposal is available here: > >

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 21, 2017, at 8:18 AM, Joe Groff wrote: >>> >> >> Yeah but Rust has a macro system so error-chain makes re-wrapping trivial. A >> simple `chain_err(|| “my new error message”)` is enough to define and >> “throw” a new error that wraps the underlying error. > > That

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution > wrote: > >> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution >> > wrote: >> My apologies for misunderstanding. >> >> Would it

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 20, 2017, at 1:15 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution >> > wrote: >> >>> On Feb 19, 2017, at 3:04 PM, Anton Zhilin via

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 19, 2017, at 12:04 PM, Anton Zhilin via swift-evolution > wrote: > > It’s expected that if you need resilience, then you will throw an “open” > enum. Essentially, we pass resilience of typed throws on to those who will > hopefully establish resilience of

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

> On Feb 16, 2017, at 9:50 PM, Xiaodi Wu via swift-evolution > wrote: > > As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised > proposal in draft form. > > It proposes a source-breaking change for rationalizing which characters are > permitted

Re: [swift-evolution] The lack of namespaces is leading people astray

> On Jan 30, 2017, at 5:55 AM, Tuur Anton via swift-evolution > wrote: > > The lack of namespaces is making people create all kinds of "design patterns". > > > What do you think? > I’ve used languages with namespaces for many years. I don’t find multi-level

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 27, 2017, at 2:08 PM, Freak Show via swift-evolution > wrote: > > Maybe so - but IB M > solved this very problem along with release to release binary compatibility > for C++ and a number of other languages twenty years ago with the System > Object Model

Re: [swift-evolution] Strings in Swift 4

If you haven’t seen Perl 6 grammars, I highly suggest taking a look. https://perl6advent.wordpress.com/2009/12/21/day-21-grammars-and-actions/ https://docs.perl6.org/language/grammars

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

> >> On Jan 24, 2017, at 8:56 AM, Daniel Dunbar via swift-build-dev >> > wrote: >> >> Hello Swift community, >> >> The review of SE-0149 “ Package Manager Support for Top of Tree development" >> begins now and runs through January

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

I never agreed with removing it so this gets a bit fat +1 from me. Russ > On Jan 24, 2017, at 2:32 PM, Robert Widmann via swift-evolution > wrote: > > Hello Swift Community, > > Harlan Haskins and I have been working on libraries >

Re: [swift-evolution] Strings in Swift 4

> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution > wrote: > > ### Formatting > > A full treatment of formatting is out of scope of this proposal, but > we believe it's crucial for completing the text processing picture. This > section details some of

Re: [swift-evolution] Strings in Swift 4

> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution > wrote: > >> >> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution >> > wrote: >> >> >>> On Jan 23, 2017, at 7:49 AM, Joshua

Re: [swift-evolution] Reduce with inout

> On Jan 22, 2017, at 10:56 PM, Chris Eidhof wrote: > > Not as a direct reply to Russ, but just to reiterate: to me, there are two > clear benefits of using the `inout` version of reduce: > > 1. The performance (currently discussed at length) > 2. Readability (because we can

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

> On Jan 22, 2017, at 4:53 PM, Dave Abrahams via swift-evolution > wrote: > > Sent from my iPad > > On Jan 22, 2017, at 3:15 PM, Chris Lattner > wrote: > >> >>> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via

Re: [swift-evolution] Reduce with inout

> On Jan 20, 2017, at 11:27 PM, Charles Srstka wrote: > >> On Jan 21, 2017, at 12:37 AM, Russ Bishop > > wrote: >> >>> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution >>>

Re: [swift-evolution] Reduce with inout

> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution > wrote: > I don’t even know how long it actually takes to finish this test, because the > last time I did this I eventually got sick of waiting and killed the process. > So, I don’t know quite how

Re: [swift-evolution] Assigning to 'self' in protocol extensions

> On Jan 19, 2017, at 11:11 PM, Slava Pestov via swift-evolution > wrote: > > >> On Jan 19, 2017, at 10:52 PM, rintaro ishizaki via swift-evolution >> > wrote: >> >> From the perspective of the caller, I

Re: [swift-evolution] Strings in Swift 4

> On Jan 19, 2017, at 8:20 PM, Xiaodi Wu via swift-evolution > wrote: > > Clearly too big to digest in one take. Some initial thoughts: > > * Not sure about the wisdom of the ad-hoc Substring : String compiler magic. > It seems that whatever needs overcoming here

Re: [swift-evolution] Compiler Optimization of Optional-returning Functions followed by '!'

> On Jan 19, 2017, at 4:17 PM, Xiaodi Wu via swift-evolution > wrote: > > For those times when you _don't_ know how many elements there are, don't > care, and for some reason can't be bothered to get `array.count`, but you > need to explicitly access an element by

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

> On Jan 19, 2017, at 5:04 PM, Slava Pestov via swift-evolution > wrote: > > Can we also add mention that default arguments on subscripts should work as > well? This will force whoever implements this to do it properly and rip out > the old RValue-based argument

Re: [swift-evolution] Throws? and throws!

I’m not sure I like this specific proposal, but the idea of having the option of catching a certain class of runtime errors is appealing. I don’t think it makes sense to abort a server process (potentially dropping X threads and thousands of connections on the ground) because one stray thread

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

> On Jan 11, 2017, at 10:35 AM, Erica Sadun <er...@ericasadun.com> wrote: > >> >> On Jan 10, 2017, at 10:35 PM, Russ Bishop via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>>

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

> On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution > wrote: > > >> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> I thought there is already a pending proposal on typed throws? > > There was, I

Re: [swift-evolution] Enhanced Existentials

> On Jan 7, 2017, at 9:17 PM, Douglas Gregor wrote: > > > > Sent from my iPhone > >> On Jan 6, 2017, at 11:04 PM, Russ Bishop wrote: >> >> >>> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution >>> wrote: >>>

Re: [swift-evolution] Enhanced Existentials

> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution > wrote: > > >> >> Would love to see this come forward into discussion. > > Yeah. I'm less sure about the other enhancements to existentials fitting into > Swift 4, e.g., the creation of

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

> On Nov 19, 2016, at 9:48 PM, Anders Bertelrud via swift-build-dev > wrote: > > Hello Swift community, > > The review of "SE-0145: Package Manager Version Pinning" begins again after > revisions, starting now and running through November 28th. The proposal is >

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

> On Nov 12, 2016, at 9:54 PM, Daniel Dunbar wrote: >> >> >> It seems like you’re going through contortions to deal with arbitrary >> directory layouts and some odd consequences fall out of that decision. Not >> being able to deterministically detect non-unique

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev > wrote: > > Hi all, > > I'm reposting a request for feedback on my proposal for extending SwiftPM to > support multiple packages inside one repository (i.e. "monorepo" support, > although it is a

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

> On Nov 10, 2016, at 8:42 PM, John McCall via swift-evolution > wrote: > > Ok. You're right, I was thinking about arrays more than I was thinking about > strings. > > Anyway, if you're talking about returning the value back, you're talking about > something we

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

I endorse the updated proposal. It’s a good step forward and doesn’t close any doors on future features, plus it will allow a lot of libraries to throw away a good chunk of boilerplate. Russ > On Nov 9, 2016, at 4:03 PM, Joe Groff via swift-evolution > wrote: >

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

orrected. I’m not aware of anything in Unicode that says it is acceptable to just drop unknown characters. I think some ZJW sequences or modifiers can be ignored; anything that can be ignored for rendering should be ignored for uniqueness of identifiers too. Russ > > On Tue, Oct

[swift-evolution] [Pitch] Expanded type category constraints

Do we already have a proposal for expanding constraints to support categories beyond class? I am guessing this might have ABI stability concerns, or at least library resilience concerns. If so and no one else has tackled it I’m happy to write up a proposal. There are only a couple that I know

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 24, 2016, at 9:43 AM, Joe Groff via swift-evolution > wrote: > > >> On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution >> > wrote: >> >> >>> On Oct 18, 2016, at 11:34 PM, Jacob

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

> On Oct 17, 2016, at 11:45 PM, Rien via swift-evolution > wrote: > > “culturally offensive” is not a logical argument. > A programming language should be logically consistent no matter how many > cultures are offended by it. > If Swift is driven by SJW’s then very

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 19, 2016, at 1:46 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I was in the middle of writing about my opposition to the original proposal > when I went to bed last night, and was going to advocate something like this: > >> Given the current

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Strong -1 from me as currently written. There is no reason to remove Emoji from identifiers, nor to restrict operators to ASCII only (especially since the corresponding UAX spec is still under construction). Emoji are just as much a part of modern communication as the Latin alphabet. Swift

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

> On Oct 14, 2016, at 12:59 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" > begins now and runs through October 18. The proposal is available here: > > >

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Oct 11, 2016, at 12:26 AM, Adrian Zubarev via swift-evolution > wrote: > > This is the latest draft of the proposal: > https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md > >

Re: [swift-evolution] private & fileprivate

> On Oct 10, 2016, at 9:59 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution >> > wrote: >> >>> >>> On Oct 7, 2016, at 15:15, William

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

> On Oct 11, 2016, at 2:28 PM, Nate Cook via swift-evolution > wrote: > > Inefficient > Value Mutation > > Dictionary values can be modified through the keyed

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

> On Oct 3, 2016, at 9:23 AM, Joe Groff wrote: > >> >> On Sep 30, 2016, at 10:48 PM, Russ Bishop wrote: >> >> >>> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> >>> Personally, I

Re: [swift-evolution] private & fileprivate

> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution > wrote: > > I started the topic, but I also believe like you that the fileprivate vs > private(file) discussion has already been thoroughly discussed and nothing > new has been brought up. That’s not

Re: [swift-evolution] [Pitch] Making some RawRepresentable things bridge to ObjC as their raw value

> On Sep 29, 2016, at 11:45 AM, Douglas Gregor via swift-evolution > wrote: >> > > > Personally, I consider the first one to be a fairly-low-risk extension to > SE-0139 that’s borderline bug-fix. We already know that those types have weak > numeric

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

> On Sep 28, 2016, at 3:15 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of “Conditional Conformances” begins now and runs through October > 7. The proposal is available here: > > >

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Sep 29, 2016, at 7:29 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Sep 29, 2016, at 3:24 PM, Russ Bishop via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Why would we not have type(of:) and subtype(o

Re: [swift-evolution] [Pitch] Refactor Metatypes

> On Sep 28, 2016, at 3:18 AM, Adrian Zubarev via swift-evolution > wrote: > > func unsafeBitCast(_: T, to type: Type) -> U > func ==(t0: Subtype?, t1: Subtype?) -> Bool > func type(of: T) -> Subtype // SE-0096 > That last example, type(of:), is rather

Re: [swift-evolution] [Proposal draft] Conditional conformances

> On Sep 29, 2016, at 11:12 AM, Douglas Gregor wrote: > >> >> On Sep 28, 2016, at 9:48 PM, Russ Bishop > > wrote: >> >> What other designs were considered and rejected? It seems like some kind of >> escape hatch would be

Re: [swift-evolution] [Proposal draft] Conditional conformances

> On Sep 26, 2016, at 5:18 PM, Douglas Gregor via swift-evolution > wrote: > > Conditional conformances > > > Disallow > overlapping conformances > >

Re: [swift-evolution] Mark protocol methods with their protocol

> On Sep 20, 2016, at 4:34 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Sep 20 2016, Karl wrote: > >> I think the best way is to prefix the member name with the protocol, e.g: >> >> protocol MyProto { >>var aVariable : Int >>func

Re: [swift-evolution] Type-annotated throws

> On Aug 26, 2016, at 8:39 AM, Félix Cloutier via swift-evolution > wrote: > > Hi all, > > Currently, a function that throws is assumed to throw anything. There was a > proposal draft last December to restrict that. The general idea was that > you'd write, for

Re: [swift-evolution] [Swift4][Pitch] Control struct layout with @layout, @offset, @order

No problem, I'll put it on the back burner for the time being. Russ > On Aug 19, 2016, at 12:50 PM, Joe Groff <jgr...@apple.com> wrote: > > >> On Aug 17, 2016, at 11:28 AM, Russ Bishop via swift-evolution >> <swift-evolution@swift.org> wrote: >

[swift-evolution] [Swift4][Pitch] Control struct layout with @layout, @offset, @order

I wanted to gauge the interest in supporting explicit struct layout and alignment. The general idea would be to support attributes to create packed structs and set alignment. It will be critical for certain kinds of interop and systems programming in pure Swift. I don’t know about you but I

[swift-evolution] [Pitch][stdlib] Command Line Option Parsing & Help

I want to pitch a command line parsing addition to the standard library and get feedback before I polish up a full proposal. Swift is being positioned to fill numerous functions, including as a local scripting language. I think that’s great but having tried to use it for that purpose there are

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

> On Jul 5, 2016, at 4:11 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > >

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

> On Jun 30, 2016, at 4:23 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md > >

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 30, 2016, at 3:37 PM, Dave Abrahams wrote: > > I use it in a LazyRowSequence where querying Sqlite in WAL mode allows multiple concurrent readers to get point-in-time snapshots of the database. The query can’t be replayed without buffering all

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

> On Jun 30, 2016, at 12:30 PM, Dave Abrahams via swift-evolution > wrote: > > I am still very skeptical that anyone needs the “Value” version, and as > long as we're resyntaxing I am inclined to take it away and see how many > people complain. You can still always

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

> On May 17, 2016, at 11:52 AM, Austin Zheng via swift-evolution > wrote: > > I put together the skeleton of a proposal detailing enhancements to how > associated types can be referenced in Swift 3+. It's certainly not ready for > submission, but I think it gets

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 30, 2016, at 10:26 AM, Dave Abrahams via swift-evolution > wrote: > > It would > be very interesting to know about any real-world models of single-pass > sequences that people are using in Swift, since we don't supply any in > the standard library. > > --

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

> On Jun 29, 2016, at 4:38 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Additionally, I believe the other un-defaulted associated types we'd like to > infer if we can—`Collection.Index`, `Sequence.Iterator`, and > `IteratorProtocol.Element`—could all be

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

> On Jun 29, 2016, at 12:33 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0108: Remove associated type inference" begins now and runs > through July 4. The proposal is available here: > > >

Re: [swift-evolution] Prohibit invisible characters in identifier names

Doesn't Unicode have a standard for this that specified which characters are look-alikes? Russ > On Jun 21, 2016, at 7:48 AM, Vladimir.S via swift-evolution > wrote: > > >> On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote: >> >>> On Jun 21, 2016, at

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 27, 2016, at 9:39 AM, Dave Abrahams via swift-evolution > wrote: > > Perhaps the language should accept types conforming to either of two > unrelated protocols (your Sequence and Iterator, as you've described > them, with no refinement relationship) for

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

> On Jun 27, 2016, at 1:26 PM, Jordan Rose via swift-evolution > wrote: > > Hey, all. An engineer at Apple noticed the following behavior: > > 1. class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) > runtime name > 2. @objc class Foo: NSObject →

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 23, 2016, at 6:40 PM, Andrew Trick via swift-evolution > wrote: > > I sent two RFC's for this proposal over the past couple months (see Early > swift-evolution threads). High-level feedback was fairly light. This version > is a final draft, as I expect it

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

> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution > wrote: > > >> - 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

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

> On Jun 23, 2016, at 7:14 PM, Erica Sadun via swift-evolution > wrote: > > >> On Jun 23, 2016, at 7:34 PM, William Shipley via swift-evolution >> > wrote: >> >> I’m against removing “where" from

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 23, 2016, at 12:26 AM, Jonathan Hull via swift-evolution > wrote: > > What are the actual use-cases where people have needed destructive iterators? > Every time I have thought I wanted it, I ended up wanting multi-pass later. > For example, I had a

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 22, 2016, at 6:12 PM, Matthew Johnson via swift-evolution > wrote: > >> E.g., the current Iterator could gain a >> class constraint and become the only representation of single-pass >> sequences. > > Hmm. I would have to give this more thought. Do we

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

> On Jun 26, 2016, at 12:10 PM, Christopher Kornher via swift-evolution > wrote: > > I may be too late for Swift 3, but I am planning to propose changes to the > default behavior for closures capturing object references. The introduction > of Swift Playgrounds has

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 9:42 AM, Dave Abrahams via swift-evolution > wrote: > > > If your code has many manual type erasing wrappers corresponding to > protocols with associated types and/or Self requirements that also never > have to trap type mismatches, that would

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 8, 2016, at 3:18 PM, Dave Abrahams via swift-evolution > wrote: > > Exactly. But much simpler cases will also either have to trap at > runtime or be prohibited outright: > > func subscript_(c: C, i: C.Index) -> C.Collection.Element { >return c[i] > }

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 2:05 PM, Xiaodi Wu wrote: > > > In the earlier conversation, it was pointed out (by Dave A., I think?) that > examples such as Array.size show how this solution can get confusing. And > even though there aren't fixed-length arrays in Swift, those may

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

> On Jun 2, 2016, at 9:08 AM, John McCall via swift-evolution > wrote: > > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed context, like so: > let x: UInt16 = 7 > or > let x = 7 as UInt16 > >

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution > wrote: > > I still think the value-based APIs are misleading and that it would be better > to ask people to just use a type explicitly. > > John. I agree; in fact why aren’t these properties on the

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

>> On May 27, 2016, at 5:30 PM, Erica Sadun via swift-evolution >> wrote: >> >> >>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon >>> wrote: >>> guard x == 0 && a == b && c == d && let y = optional, w = optional2, v =

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

> > UnsafeBytePointer API for In-Memory Layout > > UnsafePointer and UnsafeMutable refer to a typed region of memory, and the > compiler must be able to assume that UnsafePointer element (Pointee) type is > consistent with other access to the same memory. See proposed Type Safe > Memory

Re: [swift-evolution] Mutability for Foundation types in Swift

There aren’t enough +1s in the world for this, I fully endorse your proposal and would like to subscribe to your newsletter ;) Do you envision the apinotes will be the vehicle for performing the bridging since ObjectiveCBridgeable was deferred? I actually haven’t checked if that was merged but

Re: [swift-evolution] Requesting default values for Cocoa/Cocoa Touch APIs

Wouldn’t this be the responsibility of UIKit/AppKit teams to provide extensions that pass the default values? Russ > On Apr 8, 2016, at 10:40 AM, Erica Sadun via swift-evolution > wrote: > > Is there a best way to request default values for common Cocoa and Cocoa

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

> On Apr 5, 2016, at 5:57 PM, Kevin Lundberg via swift-evolution > wrote: > > Generally I'm +1 on this, but I do have a concern. It's not made explicit in > the proposal, but I presume that this is meant to only be available on > Darwin, and not Linux or other

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

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution > wrote: > > >> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >> > wrote: >>> Would using another word or symbol fix that

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

> On Apr 5, 2016, at 10:14 AM, Douglas Gregor wrote: >> >>> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this >>> Objective-C API: >>> >>> ObjCMutableFizzer* mutableFizzer; >>> >>> Which of these represents how it is imported? >>> >>> var

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

> On Mar 31, 2016, at 8:27 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0056 "Allow trailing closures in `guard` conditions" begins > now and runs through April 5, 2016. The proposal is available here: > >

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md > > There are a number of things I'm not really clear on. > > * * * > > Consider

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

> On Mar 2, 2016, at 5:22 PM, Douglas Gregor via swift-evolution > wrote: > > > Removing unnecessary restrictions > > Concrete same-type requirements > > Currently, a constrained extension cannot use a same-type constraint to make > a type parameter equivalent to

Re: [swift-evolution] [Pre-proposal/Idea] Auto-generate Type-Erased Wrappers

> On Apr 4, 2016, at 3:07 PM, Haravikk via swift-evolution > wrote: > > One of the things that threw me when starting with Swift was the inability to > use many protocols as types, e.g- being unable to declare: [SequenceType], > instead having to do: [AnySequence]

Re: [swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

> * What is your evaluation of the proposal? Generally I like the proposal and I think it helps solidify the bridging story. On casting: In our coding standards, any use of “as!” warrants much higher scrutiny (any use of try! or IUOs gets the same treatment). For a type that opts-in to

Re: [swift-evolution] [swift-evolution-announce] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

This seems like it would be a useful facility in general - the community may be able to provide audited headers even if the maintainers of the original project have zero interest in merging those changes. That burden is unreasonably high if it requires constant merging of the headers. Russ >

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

> On Mar 30, 2016, at 9:59 AM, Joe Groff via swift-evolution > wrote: > > Many people are surprised when they find out defaulted parameters can be > reordered, unlike required arguments. This special case adds complexity to > the language, and runs against our

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

> On Mar 29, 2016, at 10:14 AM, Dave Abrahams via swift-evolution > wrote: > > > I'm not objecting at all. It's an obvious thing for us to do, and we > should do it at some point. It just doesn't seem very impactful or > crucial. I use typealiases as a form of

Re: [swift-evolution] [Review] SE-0016 - Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer

d like to note that (IIUC) one of our goals is to make unsafeBitCast > unneccessary; if a conversion is a reasonable thing to do regularly, there > should always be a more principled way to do it. Someone's "intuitive" > understanding of unsafeBitCast may well be wrong. > &

Re: [swift-evolution] [Review] SE-0016 - Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer

Thinking through this proposal, I really favor the operator approach rather than adding these conversions so my vote is -1. (If you really know what you're doing you can already do an unsafeBitCast so this isn't a problem I've had in the real world) >Because some of these operations are

Re: [swift-evolution] Notes from Swift core team 2016-03-23 design discussion

> On Mar 24, 2016, at 1:26 PM, Chris Lattner <clatt...@apple.com> wrote: > > >> On Mar 24, 2016, at 11:57 AM, Russ Bishop via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

>> I added a separate section on Ambiguity and what the behavior is. I think >> you should be able to resolve ambiguity by casting so I went ahead and put >> that in. An example: >> >> //Bar and Foo bridge to SomeObjectiveCType >> struct Bar: ObjectiveCBridgeable { } >> struct Foo:

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

> On Mar 23, 2016, at 11:49 AM, Douglas Gregor wrote: >> > > Great. The suggestion to use an extension won’t actually work: > Doh. Thanks for catching that, I pushed a fix. > >> I assume this is a static function to avoid allocating memory by calling the >>

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

> On Mar 21, 2016, at 9:41 AM, Douglas Gregor <dgre...@apple.com> wrote: > > >> On Mar 9, 2016, at 12:26 PM, Russ Bishop via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> An official proposal

  1   2   >