[swift-evolution] Proposal: Allow #if to guard switch case clauses

Hi evolution community, This proposal allows you to enclose switch cases with #if directive. Implementation: https://github.com/apple/swift/pull/9457 This is one of the oldest SR issue: https://bugs.swift.org/browse/SR-2 https://bugs.swift.org/browse/SR-4196 Thanks! Rintaro Allow #if to guard s

Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

Here's proposal link: https://github.com/rintaro/swift-evolution/blob/conditional-switch-case/proposals/-conditional-switch-case.md Fixed some typos, including my name :) 2017-05-10 17:32 GMT+09:00 rintaro ishizaki : > Hi evolution community, > > This proposal allows you to enclose switch ca

Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

AM, Jordan Rose via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> I'm in favor, certainly. I'd personally say this wouldn't even need to go >> through the full evolution process, but I'm not a core team member. >> >>

Re: [swift-evolution] Revisiting SE-0110

2017-06-05 2:16 GMT+09:00 Chris Lattner via swift-evolution < swift-evolution@swift.org>: > > On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic wrote: > > On Thu, Jun 1, 2017 at 8:52 PM, John McCall v

Re: [swift-evolution] Revisiting SE-0110

My guess is that core team is planning to accept *patterns* in closure parameter clause. e.g.: let dict = ["foo": 1, "bar": 2] let result = dict.map { ((k, v) : (key: String, value: Int)) in ... } ^^ pattern When the compiler see this expression: dict.map { k

Re: [swift-evolution] [pitch] Substring performance affordances

Hi, Just a quick question. Does this mean it's guaranteed that Substring.hashValue is always equal to String.hashValue? ``` let foobar: String = "foo bar" let sliced: Substring = foobar.suffix(3) let bar = "bar" bar.hashValue == sliced.hashValue // guaranteed? ``` 2017-06-29 1:37 GMT+09:00 Ben

Re: [swift-evolution] [Pitch] Contextual variables

2017-06-28 21:33 GMT+09:00 Dimitri Racordon via swift-evolution < swift-evolution@swift.org>: > Hello community! > > I’d like to pitch an idea for a user-friendly way for functions to pull > values from an arbitrary environment. Let me introduce the concept with a > motivational example before I d

Re: [swift-evolution] [Pitch] Contextual variables

2017-07-03 11:23 GMT+09:00 rintaro ishizaki via swift-evolution < swift-evolution@swift.org>: > > > 2017-06-28 21:33 GMT+09:00 Dimitri Racordon via swift-evolution < > swift-evolution@swift.org>: > >> Hello community! >> >> I’d like to pitch an idea

Re: [swift-evolution] [Pitch] Contextual variables

contextVal) } I don't think this is guaranteed to work. 2017-07-03 11:48 GMT+09:00 rintaro ishizaki via swift-evolution < swift-evolution@swift.org>: > > > 2017-07-03 11:23 GMT+09:00 rintaro ishizaki via swift-evolution < > swift-evolution@swift.org>: > &

[swift-evolution] [Pitch] Scoped @available

Hi evolution community, I would like to propose "Scoped @available" attribute. What I want to achieve is to declare something that is publicly unavailable, but still usable from narrower scope. A concrete example is IndexableBase in the standard library: https://github.com/apple/swift/blob/master

Re: [swift-evolution] [Pitch] Scoped @available

ivate) open Hmm.. 🤔 Any suggestions will be greatly appreciated! > On Sun, Jul 9, 2017 at 22:40 rintaro ishizaki via swift-evolution < > swift-evolution@swift.org> wrote: > >> Hi evolution community, >> >> I would like to propose "Scoped @available" attr

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

I don't think it's worthwhile adding new API. I think this is simple enough: let views = Array(AnyIterator(UIView.init).prefix(3)) 2017-08-17 21:04 GMT+09:00 Robert Bennett via swift-evolution < swift-evolution@swift.org>: > Alternatively, instead of replacing the current definition with an > au

Re: [swift-evolution] MemoryLayout for a value

> ``` > extension MemoryLayout { > static func size(ofValue _: T) -> Int { return MemoryLayout.size } > // etc. > } > ``` I don't think we can do this while we have: public static var size: Int { maybe `sizeOf(value _: T) -> Int` ? 2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution

Re: [swift-evolution] MemoryLayout for a value

2016-08-05 16:20 GMT+09:00 Xiaodi Wu : > On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki > wrote: > >> > ``` >> > extension MemoryLayout { >> > static func size(ofValue _: T) -> Int { return MemoryLayout.size } >> > // etc. >> > } >> > ``` >> >> I don't think we can do this while we have: >>

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

* What is your evaluation of the proposal? +1 We should do the best to avoid source breaking change in Swift4. https://github.com/ankurp/Dollar is used in so many projects. I believe removing this might discourage them from using Swift. * Is the problem being addressed significant

[swift-evolution] [Pitch] Limiting member expression with right-bound period

Hi all, The compiler currently accepts these expressions: x = expr . member x = expr . member x = expr . member x = . implicitMember I propose to reject them because this could cause some unnecessary confusion. (especially after SE-0071

Re: [swift-evolution] [Pitch] Limiting member expression with right-bound period

t; .first > > is also pretty clean, considering. > > > On Nov 1, 2016, at 11:06 PM, rintaro ishizaki via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi all, > > The compiler currently accepts these expressions: > > x = expr . member > x = expr

Re: [swift-evolution] [Proposal] Linux specific Package.swift file

Hi Said, Since `Package.targets` is a mutable public property, https://github.com/apple/swift-package-manager/blob/master/Sources/PackageDescription/Package.swift#L60-L67 you can freely mutate it later, as documented in https://github.com/apple/swift-package-manager/blob/master/Documentation/Refer

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

2016-11-20 14:48 GMT+09:00 Anders Bertelrud via swift-evolution < swift-evolution@swift.org>: > 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 available here: >

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

Hi all, I just want to raise an issue. I currently don't have any concrete ideas about it, but I believe we should discuss this before ABI stabilization. Default implementation for mutating methods Swift protocol extension allows assigning to self in default implementations for mutating methods:

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

2017-01-20 16:11 GMT+09:00 Slava Pestov : > > Is your proposal to ban calls to such mutating methods on a type that is > known to be a reference type at compile time altogether? This will create > an inconsistency between code that operates on concrete types and code that > operates on generic par

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

> In the specific case of initializers, my opinion here is the opposite in >> fact — I think assigning to ‘self’ should be permitted in all convenience >> initializers, even initializers defined directly classes, without the >> protocol extension trick. Also, we should lower this more efficiently t

Re: [swift-evolution] [Draft] Abolish IUO type

Oops, typo in the example code: let foo: Int! = 42 let bar = (foo as ImplicitlyUnwrappedOptional).map { UInt($0) } 2016-03-18 14:05 GMT+09:00 rintaro ishizaki : > What will happen to map()/flatMap() on IUO attributed optional values? > > let foo: Int! = 42 > let bar = (foo as ImplicitlyUnwrappe

Re: [swift-evolution] [Draft] Abolish IUO type

What will happen to map()/flatMap() on IUO attributed optional values? let foo: Int! = 42 let bar = (foo as ImplicitlyUnwrappedOptional).map { $0.UInt($0) } Replacement would be something like this? let bar: UInt! = (foo as Int?).map { UInt($0) } I have never seen code like this in real world

Re: [swift-evolution] [Proposal] Factory Initializers

FWIW, even in Swift2, factory initializer is possible. I've post a gist here: https://gist.github.com/rintaro/9eadc2720ac8be6a7898 It's pretty hackish though :) 2016-03-22 15:16 GMT+09:00 Riley Testut via swift-evolution < swift-evolution@swift.org>: > Hey all! > > Very sorry, restored my MacBo

Re: [swift-evolution] [proposal] Move @noescape and @autoclosure to type attributes

After this proposal [SE-0049] is accepted: Is the following code valid? func foo(arg: @autoclosure () -> Bool) { } let value: @autoclosure () -> Bool = false foo(value) If so, I feel `@autoclosure T` is more natural than `@autoclosure () -> T` let value: @autoclosure Bool = false func foo(arg:

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

+1 I prefer foo(:) because it matches with empty dictional literal [:]. Also, foo(_) potentially introduce a confusion. Remember that this syntax can be appear in a pattern. ``` struct S { let val: Int } func newS() -> S { return S(val: 0) } func newS(_ val: Int) -> S { return S(val: val) }

Re: [swift-evolution] Inconsistencies in recursive types

FWIW, there *is* a way to instantiate #4 case. class First { let item: First init(item: First) { self.item = item } } class Second : First { init() { super.init(item: self) } } let a: First = Second() 2017-03-13 22:38 GMT+09:00 Dimitri Racordon via swift-evo

Re: [swift-evolution] Inconsistencies in recursive types

final class First { let item: First init(item: First) { self.item = item } } extension First { convenience init() { self.init(item: self) } } let a = First() I'm actually a bit surprised that this compiles. This should be diagnosed as: "error: 'self' used befo