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

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

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

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

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

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

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

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

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 >>

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

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

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

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,

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

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 >>>

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

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

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

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: >

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:

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

[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

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

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

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

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

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

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,

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

On Oct 3, 2017, at 21:47, Chris Lattner > wrote: > >> On Oct 3, 2017, at 4:05 PM, David Sweeris > > wrote: >> >> >>> On Oct 2, 2017, at 10:06 PM, Chris Lattner >>

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

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

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

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

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 >

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

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 {

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

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

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

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

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

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 >> >

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

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: >> >>

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:

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

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

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

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

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,

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

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

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

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

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 -> Self static func random(in range: ClosedRange)throws -> Self On Double:

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

> On Oct 3, 2017, at 11:05 PM, Jonas B wrote: > > >> On 4 Oct 2017, at 14:33, Slava Pestov > > wrote: >> >> @_versioned makes a symbol visible externally without making it visible from >> the language. There is no requirement

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

> On 4 Oct 2017, at 14:33, Slava Pestov wrote: > > @_versioned makes a symbol visible externally without making it visible from > the language. There is no requirement that a @_versioned thing is @inlinable. > It is used when you want to reference an internal function from