Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 6, 2017, at 9:35 PM, Tony Allevato wrote: > > > > On Fri, Oct 6, 2017 at 9:29 PM Jose Cheyo Jimenez > wrote: >> On Oct 6, 2017, at 8:58 PM, Tony Allevato > > wrote: >> >> >> >> On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Ji

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Fri, Oct 6, 2017 at 9:29 PM Jose Cheyo Jimenez wrote: > On Oct 6, 2017, at 8:58 PM, Tony Allevato wrote: > > > > On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez > wrote: > >> On Oct 6, 2017, at 8:01 PM, Tony Allevato >> wrote: >> >>> >>> At the time SE-0025 was accepted, "private extensio

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 6, 2017, at 8:58 PM, Tony Allevato wrote: > > > > On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez > wrote: >> On Oct 6, 2017, at 8:01 PM, Tony Allevato > > wrote: >> >> At the time SE-0025 was accepted, "private extension

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Fri, Oct 6, 2017 at 8:45 PM Jose Cheyo Jimenez wrote: > On Oct 6, 2017, at 8:01 PM, Tony Allevato wrote: > >> >> At the time SE-0025 was accepted, "private extension" would have been > meaningless if it did not mean "fileprivate" because it predated the > SE-0169 behavior extending "private"

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 6, 2017, at 8:01 PM, Tony Allevato wrote: > > At the time SE-0025 was accepted, "private extension" would have been > meaningless if it did not mean "fileprivate" because it predated the SE-0169 > behavior extending "private" to extensions in the same file. The very issue > being deb

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 5, 2017, at 10:58 AM, Nate Cook via swift-evolution > wrote: > > The edge case is really the same (empty ranges), it’s about what we do with > the edge case. If we include the methods on integer types, usage will look > like this: > > let x = Int.random(in: 0..<5) // 3 >

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Fri, Oct 6, 2017 at 7:07 PM Jose Cheyo Jimenez wrote: > On Oct 6, 2017, at 11:07 AM, Tony Allevato > wrote: > > On Fri, Oct 6, 2017 at 10:16 AM Jose Cheyo Jimenez via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Oct 6, 2017, at 7:10 AM, Vladimir.S wrote: >> >> On 05.10.2017

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 6, 2017, at 11:07 AM, Tony Allevato wrote: > > On Fri, Oct 6, 2017 at 10:16 AM Jose Cheyo Jimenez via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> On Oct 6, 2017, at 7:10 AM, Vladimir.S > > wrote: >> >> On 05.10.2017 20:52, Jose Cheyo Jimenez

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

Oh, sorry, the missing piece of that is 'inlinable': an inlinable memberwise initializer in a fixed-layout struct should have no performance overhead in an optimized build. Jordan > On Oct 6, 2017, at 15:25, Jordan Rose wrote: > > Good question. Slava and I talked about that and decided that

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

Good question. Slava and I talked about that and decided that there wasn't much point. '_fixed_layout' still doesn't cover the invariant problem, and memberwise initializers are really common when that's not relevant. We don't think there should ever be a reason to write _fixed_layout in a sourc

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

Presumably, @_fixed_layout and its future formalized cousin would restore the current functionality? On Fri, Oct 6, 2017 at 16:32 Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > While working on the non-exhaustive enums proposal I had it pointed out to > me that *structs* a

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

Yes, this feels right. I was a little unsure/unclear about this at first, but the example with `let` and invariants convinced me, and now I can see how changing a stored property to a computed property later could cause problems in your scenario. So even though *technically* there is some subset o

[swift-evolution] Pitch: Restrict Cross-module Struct Initializers

While working on the non-exhaustive enums proposal I had it pointed out to me that structs actually currently leak implementation details across module boundaries, specifically their full set of stored properties. This only comes up in one place: when making an initializer for the struct in an e

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 4, 2017, at 19:26, Xiaodi Wu via swift-evolution > wrote: > > extension Data { > static func random(byteCount: Int) -> Data > } > Instead of methods on specific concrete types, I’d prefer to have a Sequence or Collection-conforming type that you could compose with existing opera

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Fri, Oct 6, 2017 at 10:16 AM Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote: > On Oct 6, 2017, at 7:10 AM, Vladimir.S wrote: > > On 05.10.2017 20:52, Jose Cheyo Jimenez via swift-evolution wrote: > > On Oct 5, 2017, at 4:32 AM, David Hart mailto:da...@hartbit.com >>

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

These exceed the confines of the narrow discussion we are trying to have here about private extensions. We are not going to rehash the ugliness of fileprivate. On Fri, Oct 6, 2017 at 12:16 Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote: > On Oct 6, 2017, at 7:10 AM, Vlad

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 6, 2017, at 7:10 AM, Vladimir.S wrote: > > On 05.10.2017 20:52, Jose Cheyo Jimenez via swift-evolution wrote: >>> On Oct 5, 2017, at 4:32 AM, David Hart >> > wrote: >>> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution mailto:swi

Re: [swift-evolution] [Proposal] Random Unification

I agree that as an operation, .randomElement() feels closer to .first and .last (check that there's an element in the collection) than to the subscript (trap). However, it *is* a usability sore spot on collection literals and ranges made from literals. Nobody writes [1,2,3].first, because the fi

Re: [swift-evolution] Re-initialization of lazy variables?

> On 6. Oct 2017, at 14:49, Spencer Kohan via swift-evolution > wrote: > > Hi all, > > In migrating to swift 4 I've noticed one thing which has changed is there is > no longer support for the automatic re-initialization of lazy variables. > > In swift 3 I could declare a variable like thi

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On 05.10.2017 20:52, Jose Cheyo Jimenez via swift-evolution wrote: On Oct 5, 2017, at 4:32 AM, David Hart mailto:da...@hartbit.com>> wrote: On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution > wrote: I appreciate the enthusiasm but this is not

[swift-evolution] Re-initialization of lazy variables?

Hi all, In migrating to swift 4 I've noticed one thing which has changed is there is no longer support for the automatic re-initialization of lazy variables. In swift 3 I could declare a variable like this: lazy var myVar : MyType! = { return makeMyVar() }() And then if I wanted

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Hi all, Summarizing the thread so far, I see there were three main points of discussion: - The name itself, @inlinable, is causing some confusion. Chris suggested a more general name, like @fragile. A few other possible names were discussed. I don’t think we’ve decided on the best name yet so I