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 Pestov

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> i’m just tryna follow al

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> Chris Lattner wrote: >> >>> Just FWIW, IMO, these make sense as operators specifically because they are >>> commonly used by math people as operations that transform the thing they

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 function to be emitted as a set of specialized

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 i

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

> 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 function to be emitted as a set of specialized > functions into the client, but not inlined everywhere? It can

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

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 disallowed `private extension` and only allowed `fileprivate extension` but that is not what happened. `private exte

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

Trust me, I'm the last person who wants to rehash access levels in Swift again. But that's not what's happening here, IMO, and fixing bugs is not just "a change for the sake of changing." The current behavior of "private extension" is *incorrect*, because it's entirely inconsistent with how access

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

> On Oct 4, 2017, at 9:40 PM, Taylor Swift wrote: > > > - It becomes an ABI compatibility liability that has to be preserved forever. > - It increases binary size for a function that's rarely used, and which is > often much larger as an outlined generic function than the simple operation > t

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

There was a high bar for breaking changes in swift 4 and is even higher for swift 5. se-110 was approved and implemented on the premises that it was not a big change but it was breaking code so it got reverted. Sure the migrator was making this easier but the result was a usability regression.

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

On Wed, Oct 4, 2017 at 11:44 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: > > > On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: > > > > On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution < > swift-evolution@

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

Just as one small data point, I had no idea private extensions still applied fileprivate access to all members (I thought that had changed when SE-0169 was implemented). I’ve been using private extensions extensively because I thought they *did* apply private access to everything, not fileprivat

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

> On Oct 4, 2017, at 9:24 PM, Chris Lattner via swift-evolution > wrote: > >> >> - It increases binary size for a function that's rarely used, and which is >> often much larger as an outlined generic function than the simple operation >> that can be inlined into client code. Inlining makes t

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

Glibc random is not cryptographically secure, nor is it thread-safe. getrandom() fails in more ways than arc4random and is therefore a primitive on which we can base a shim but isn't suitable by itself. Swift used to use libbsd internally on Linux but that dependency was removed. Currently, it uses

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

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 >> they are the wrong default for anything other than overlays and the wrong >> thing for long term

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

I think this is a good idea. I start asking questions about what our default generator for linux will be if we use Darwin’s arc4random(3). Do we use Glibc’s random()? If so, what do we seed it with? - Alejandro On Oct 4, 2017, 6:26 PM -0500, Ben Cohen via swift-evolution , wrote: On Sep 30,

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

> 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 the standard library. For the soon-to-be-ABI-stable libraries where @inlinable even matters, such as the standard library

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

On Oct 4, 2017, at 7:26 PM, Xiaodi Wu via swift-evolution wrote: > * Remove the range-less function. Naive users often write things like > `Int.random() % 100`, which unbeknownst to them is biased. Providing only the > ranged interface nudges naive users toward correct usage. > > * Provide an

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

> On Oct 4, 2017, at 7:07 PM, Xiaodi Wu wrote: > > On Wed, Oct 4, 2017 at 20:32 Chris Lattner > wrote: > FWIW, I agree with Ben here: if the true cryptographically secure random > numbers force this complexity onto users, then we should settle for something > close

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

It certainly could break *some* code. But it only breaks code written by an author who wrote ‘private extension’ knowing that ‘fileprivate extension’ was also an option, but still intended it to be shared with the whole file. (If that code was from Swift 2, it would have already been migrated to

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

> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution > wrote: > > > >> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution >> wrote: >> >>> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> Sent from my iPad >>> On Oct 2, 2017,

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

On Wed, Oct 4, 2017 at 21:01 Xiaodi Wu wrote: > On Wed, Oct 4, 2017 at 20:49 Greg Parker via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Oct 3, 2017, at 11:44 PM, Jonathan Hull via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> I like the idea of splitting it in

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

On Wed, Oct 4, 2017 at 20:32 Chris Lattner wrote: > FWIW, I agree with Ben here: if the true cryptographically secure random > numbers force this complexity onto users, then we should settle for > something close but not quite that bulletproof. > As long as it's a conscious design choice, that's

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

On Wed, Oct 4, 2017 at 20:49 Greg Parker via swift-evolution < swift-evolution@swift.org> wrote: > > On Oct 3, 2017, at 11:44 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > I like the idea of splitting it into 2 separate “Random” proposals. > > The first would have

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

> On Oct 3, 2017, at 11:44 PM, Jonathan Hull via swift-evolution > wrote: > > I like the idea of splitting it into 2 separate “Random” proposals. > > The first would have Xiaodi’s built-in CSPRNG which only has the interface: > > On FixedWidthInteger: > static func random()throws -> Sel

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

FWIW, I agree with Ben here: if the true cryptographically secure random numbers force this complexity onto users, then we should settle for something close but not quite that bulletproof. -Chris > On Oct 4, 2017, at 6:15 PM, Xiaodi Wu via swift-evolution > wrote: > > >> On Wed, Oct 4, 2017

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

On Wed, Oct 4, 2017 at 18:42 Ben Cohen wrote: > > On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > If trapping is OK, then surely returning Optional is superior; any user > who is OK with trapping can make that decision for themselves by writing

[swift-evolution] Resolving identifier vs. operator debates

Forking from discussion in “A path forward on rationalizing unicode identifiers and operators”, it was suggested to put this in a new thread. Background: Swift partitions the character set into operators and identifiers to aid in efficient parsing. This has the unfortunate side effect that th

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

> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution > wrote: > > If trapping is OK, then surely returning Optional is superior; any user who > is OK with trapping can make that decision for themselves by writing > `random()!`. Everyone else can then see clearly that trapping is a >

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

> On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution > wrote: > > >> On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon > > wrote: >> >>> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>>

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

After reading the original proposal and the Unicode Annex #31 document that underlies it (https://unicode.org/reports/tr31/) I think that the existing work as an underlying layer could help frame the discussion and push it forward. Although I do see the concerns about defining things too strictly

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

Couldn’t the generators just do seeding at init time, and then throw or return nil if it fails, for whatever reason? Dave > On Oct 4, 2017, at 12:28 PM, Jacob Williams via swift-evolution > wrote: > > I agree with Dave’s assertion that this should be in a separate Random > library. Not every

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

I agree with Dave’s assertion that this should be in a separate Random library. Not every project needs random numbers and there could possibly be a SecureRandom that exclusively uses CSPRNGs for it’s functionality. I also agree that trapping is not a preferred behavior. Optionals are slightly

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

On Mon, Oct 2, 2017 at 5:45 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > This is unduly restrictive; @_versioned (despite being the wrong spelling) > is what we want here. To be callable from an inlinable function, internal > things need only be visible in terms of publi

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

> On Oct 4, 2017, at 9:46 AM, Joe Groff via swift-evolution > wrote: > > > > On Oct 3, 2017, at 10:03 PM, Chris Lattner wrote: > >> >>> On Oct 3, 2017, at 10:04 AM, Joe Groff wrote: >>> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>> wrote: The major

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Oct 3, 2017, at 21:47, Chris Lattner mailto:clatt...@nondot.org>> wrote: > >> On Oct 3, 2017, at 4:05 PM, David Sweeris > > wrote: >> >> >>> On Oct 2, 2017, at 10:06 PM, Chris Lattner >> > wrote: >>> >>> On Oct 2, 2017, at 9:12 PM, Da

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

How does @inlinable relate to the @_specialize attribute described in https://github.com/apple/swift/pull/6797 (original swift-evolution post about it: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001449.html)? Here's how I understand it: @_specialize emits the specialized

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

> On Oct 3, 2017, at 10:03 PM, Chris Lattner wrote: > > >> On Oct 3, 2017, at 10:04 AM, Joe Groff wrote: >> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> The major question I have is “why yet another attribute”. The thread about >>> exhaustive/ext

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

> On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: > > >> On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: >> >> >> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution wrote: We have discussed adding a "versioned @inlinable" variant that preserves the pu

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

> On Oct 3, 2017, at 9:59 PM, Slava Pestov wrote: > > > >>> On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: >>> >>> On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: > On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution > wrote: > > We have

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

Anything that hasn't killed the process seems fine, and you have to start from `main` for anything else. On iOS, you can be suspended at any time, but the program will only continue from the point that it was suspended if it hasn't been torn down; otherwise, it has to restart from the beginning

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

The implementation is complete and building successfully: https://github.com/apple/swift/pull/12200 On Sat, Sep 30, 2017 at 2:56 PM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > https://github.com/apple/swift-evolution/pull/750 > https://github.com/apple/swift/pull/12200

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

Riffing off this a bit… I’d like to see minimal Random support in the stdlib, and then all this specialization stuff in a “non-standard” library. Ie, a library that ships with Swift, but is not imported by default. As I’m developing apps, I don’t need the massive autocompletion overload and co

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 4 October 2017 at 14:24, Alex Blewitt wrote: func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool { > return left && right() > } > FTM, it would be nice to be able to "syntax sugar-ize" it into a better looking: func &&& (left: Bool, right: lazy Bool) -> Bool { return left && rig

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

If trapping is OK, then surely returning Optional is superior; any user who is OK with trapping can make that decision for themselves by writing `random()!`. Everyone else can then see clearly that trapping is a possibility, which is important. On Wed, Oct 4, 2017 at 11:09 David Waite wrote: > >

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

> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution > wrote: > > > I agree with Felix’s concern, which is why I brought up the question, but > ultimately the issue is unavoidable. It’s not down to global instance or not. > If your source of random numbers is unseedable and may mix in

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 4 October 2017 at 14:24, Alex Blewitt wrote: > On 4 October 2017 at 13:41, Alex Blewitt wrote: > >> >> The difference between the & and && operators isn't to do with the >> implicit conversions; it's to do with whether both sides of the expression >> are evaluated or not. >> > > However, you

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 14:12, Mike Kluev wrote: > > On 4 October 2017 at 13:41, Alex Blewitt > wrote: > > The difference between the & and && operators isn't to do with the implicit > conversions; it's to do with whether both sides of the expression are > evaluated or no

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 4 October 2017 at 13:41, Alex Blewitt wrote: > > The difference between the & and && operators isn't to do with the > implicit conversions; it's to do with whether both sides of the expression > are evaluated or not. > > false && system('rm -rf') > > You really don't want to do that if both si

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 13:55, Mike Kluev wrote: > > On 4 October 2017 at 13:41, Alex Blewitt > wrote: >> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> speaking of &&, was it just a copy-paste from C or is there

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 4 October 2017 at 13:41, Alex Blewitt wrote: > On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution < > swift-evolution@swift.org> wrote: > > speaking of &&, was it just a copy-paste from C or is there a more > fundamental reason to use that instead of &? in C they had to use two > differen

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 4, 2017, at 6:41 AM, Alex Blewitt via swift-evolution > wrote: > >> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution >> wrote: >> >> on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong >> wrote: >> >> > Because, ideally, I’d love to be able to do: >> > >> > infix operator and:

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution > wrote: > > on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong > > wrote: > > > Because, ideally, I’d love to be able to do: > > > > infix operator and: LogicalConjunctionPrecedence // or whatever the > > pr

Re: [swift-evolution] Swift and actors

on Wed, 4 Oct 2017 00:16:14 +0200 Benjamin Garrigues < benjamin.garrig...@gmail.com> wrote: > Same goes for actors and blocking calls : if you're dealing with a few coarsed > grained actors that handle a large state and communicate over an unreliable > medium ( such as a network) , you're going to

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong wrote: > Because, ideally, I’d love to be able to do: > > infix operator and: LogicalConjunctionPrecedence // or whatever the precedence is called > func and(lhs: Bool, rhs: Bool) → Bool { return lhs && rhs } > > let truthyValue = true and false +1

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

On Wed, Oct 4, 2017 at 04:55 Xiaodi Wu wrote: > Seems like the API would be actively hiding he possibility of failure so > that you’d have to be in the know to prevent it. Those who don’t know about > it would be hunting down a ghost as they’re trying to debug, especially if > their program crash

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

What about the opposite then, where we internally switch to a slightly less random source, but keep the extra function so conscientious programmers can check/handle cases where there isn’t enough entropy specially if needed? Thanks, Jon > On Oct 4, 2017, at 2:55 AM, Xiaodi Wu wrote: > > Seem

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

Seems like the API would be actively hiding he possibility of failure so that you’d have to be in the know to prevent it. Those who don’t know about it would be hunting down a ghost as they’re trying to debug, especially if their program crashes rarely, stochastically, and non-reproducibly because

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

@Xiaodi: What do you think of the possibility of trapping in cases of low entropy, and adding an additional global function that checks for entropy so that conscientious programmers can avoid the trap and provide an alternative (or error message)? Thanks, Jon > On Oct 4, 2017, at 2:41 AM, Xia

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

On Wed, Oct 4, 2017 at 02:39 Félix Cloutier wrote: > I'm really not enthusiastic about `random() -> Self?` or `random() throws > -> Self` when the only possible error is that some global object hasn't > been initialized. > > The idea of having `random` straight on integers and floats and > collec

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

>> >> Anyway, for my use case mentioned earlier (shipping a release version of my >> app bundle), that doesn’t really matter. I’d just like a compiler switch >> that made the whole module not having an ABI, essentially making all all >> methods and types @inlinable and @_versioned, using the t

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

I'm really not enthusiastic about `random() -> Self?` or `random() throws -> Self` when the only possible error is that some global object hasn't been initialized. The idea of having `random` straight on integers and floats and collections was to provide a simple interface, but using a global C