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

> On 6 Oct 2017, at 06:25, David Hart via swift-evolution > wrote: > > > >> On 5 Oct 2017, at 20:23, Ben Cohen via swift-evolution >> wrote: >> >> >>> On Oct 5, 2017, at 10:58, Nate Cook via swift-evolution >>>

Re: [swift-evolution] superscripts, subscripts, etc.

> On Oct 5, 2017, at 3:57 AM, Dennis Ferguson via swift-evolution > wrote: > > I concur with Taylor and John on this particular issue. As much as I use > annotations in my daily work, I wouldn’t want the language cluttered up and > there will always be industry

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

> On 5 Oct 2017, at 20:23, Ben Cohen via swift-evolution > wrote: > > >> On Oct 5, 2017, at 10:58, Nate Cook via swift-evolution >> wrote: >> >> The edge case is really the same (empty ranges), it’s about what we do with >> the edge

[swift-evolution] [Accepted with revisions] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

Hello Swift community, Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size”

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

> On Oct 4, 2017, at 9:24 PM, Chris Lattner wrote: > > On Oct 4, 2017, at 9:44 AM, Joe Groff wrote: >>> I disagree. The semantics being proposed perfectly overlap with the >>> transitional plan for overlays (which matters for the next few years), but

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

> On Oct 5, 2017, at 1:17 PM, Michael Ilseman via swift-evolution > wrote: > > Another benefit of the always-emit-into-client-and-omit-from-libary-binary is > cross-call consistency. A function foo could change in a way such that *all* > calls using either the new

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

Another benefit of the always-emit-into-client-and-omit-from-libary-binary is cross-call consistency. A function foo could change in a way such that *all* calls using either the new or old version is fine, but some interleaving of calls to new and old versions is invalid. Having to reason about

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

> On Oct 5, 2017, at 12:01 AM, Slava Pestov via swift-evolution > wrote: > > Oh right. @_specialize modifies the original entry point to do runtime > dispatch among the possible specializations. So the overhead comes from the > unnecessary checks. I guess ideally

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

> On Oct 5, 2017, at 10:58, 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 =

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

> On Oct 5, 2017, at 10:46 AM, Taylor Swift wrote: > > why is runtime dispatch even necessary? Why can’t the client just call the > specialized version directly? Runtime dispatch on the callee side keeps the exact set of specializations open to change, since it isn't

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

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 let y = Int.random(in: 0..<0) // runtime error If we only have the collection

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

> On Oct 5, 2017, at 4:32 AM, David Hart wrote: > >> >> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution >> > wrote: >> >> I appreciate the enthusiasm but this is not a bug. This was a deliberate

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

why is runtime dispatch even necessary? Why can’t the client just call the specialized version directly? On Thu, Oct 5, 2017 at 2:01 AM, Slava Pestov wrote: > Oh right. @_specialize modifies the original entry point to do runtime > dispatch among the possible specializations.

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

Rather 0 ..< 0 my bad. I think if we include closedcountable, then there needs to be support for countable, but there are edge cases where users can input invalid ranges for countable. Enviado desde mi iPhone El oct. 5, 2017, a la(s) 12:22, Alejandro Alonso via swift-evolution

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

I agree with Ben here because users can still enter an invalid range with the static function. I.E. Int.random(in: 0 ... 0). I would really prefer excluding these static functions from numeric types. - Alejandro El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution

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

Hi Slava, What is the impact on debugging? Will we emit a non-inline version of the function into the client at Onone? Will it be impossible to call from a debugger with optimization enabled? I've been burned by this in C++. Ben > On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution

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

> On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution > wrote: > >> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution >> > wrote: >> >>> ``` >>> extension Int { >>> static func

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

> On Oct 4, 2017, at 9:15 PM, Chris Lattner wrote: > > >> On Oct 4, 2017, at 9:36 AM, Joe Groff > > wrote: >> > It wouldn't avoid the complexity, because we want the "non-ABI, > always-emit-into-client" behavior for

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

> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution > wrote: > >> ``` >> extension Int { >> static func random(in range: Countable{Closed}Range) -> Int >> } > > Nice. Should these be initializers like: > > extension Int { > init(randomIn:

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

> Le 4 oct. 2017 à 19:26, Xiaodi Wu via swift-evolution > a écrit : > To sum up my thoughts so far in code, building on previous comments from > others, this would be a nice set of random APIs, IMO: > > ``` > extension Int { > static func random(in range:

Re: [swift-evolution] superscripts, subscripts, etc.

On Tue, Oct 3, 2017 at 2:02 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > You want: > > x² to parse as “superscript2(x)” - not as an identifier “xsuperscript2” > which is distinct from x. > > -Chris I am of two minds on this. Sometimes I want x² to parse as x*x

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

> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution > wrote: > > I appreciate the enthusiasm but this is not a bug. This was a deliberate > change in swift 3 to make `private extension` usable. If this was a bug then > during swift 3 we should have

Re: [swift-evolution] superscripts, subscripts, etc.

I concur with Taylor and John on this particular issue. As much as I use annotations in my daily work, I wouldn’t want the language cluttered up and there will always be industry unique annotations that would be frustratingly unsupported (e.g. I say “j” and you say “i”). dennis. > On Oct 5,

Re: [swift-evolution] superscripts, subscripts, etc.

> On Oct 5, 2017, at 2:31 AM, Taylor Swift via swift-evolution > wrote: > not to rain on anyone’s parade here but y’all are aware unicode superscripts > don’t even form a complete alphabet right? This kind of syntax would really > only work for positive integer

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

Oh right. @_specialize modifies the original entry point to do runtime dispatch among the possible specializations. So the overhead comes from the unnecessary checks. I guess ideally we would have two versions of @_specialize, one adds the runtime dispatch whereas the other one just publishes

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

See the thread from july over generic trig functions, where @_specialize() + @_inlineable had a small but consistent performance penalty relative to @_inlineable alone. On Thu, Oct 5, 2017 at 1:32 AM, Slava

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

> On Oct 4, 2017, at 11:04 PM, Taylor Swift wrote: > > > > On Oct 5, 2017, at 12:52 AM, Slava Pestov > wrote: > >> >> >>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution >>>

Re: [swift-evolution] superscripts, subscripts, etc.

not to rain on anyone’s parade here but y’all are aware unicode superscripts don’t even form a complete alphabet right? This kind of syntax would really only work for positive integer literals and I don’t think making a wholesale change to the language like this is worth that. On Thu, Oct 5, 2017

Re: [swift-evolution] superscripts, subscripts, etc.

Going a little further... It’s not hard to imagine a situation where the order of a trailing annotation matters. Ie, that X²₃ is a different thing from X₃². (X squared sub 3 ≠ X sub 3 squared) So i think you’d want an array of trailing annotations and an array of leading annotations, where an

Re: [swift-evolution] superscripts, subscripts, etc.

>> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution >> > wrote: >> >> Chris Lattner wrote: >> >>> Just FWIW, IMO, these make sense as operators specifically because they are >>> commonly used by math people as operations

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

> On Oct 5, 2017, at 12:52 AM, Slava Pestov wrote: > > > >> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution >> wrote: >> >> i’m just tryna follow along here && this is probably a dumb question, but is >> it possible for a generic

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

Yes, you're right about the history of "private extension"—I was forgetting some of the details of what transpired during those proposals. Thanks for the reminder. That being said, I would still argue that it would be a shame if we decided that the language should propagate a known inconsistency