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

This is a great proposal, I’m a strong supporter, but have one question and one strong push back: > On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution > wrote: > Introduction > We propose introducing an @inlinable attribute which exports the body of a >

[swift-evolution] superscripts, subscripts, etc.

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 are > attached to. Superscript 2 is a function that squares its operand. That > said, perhaps there are other uses

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

On Mon, Oct 2, 2017 at 11:12 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > Maybe they've started teaching it earlier than when I went through > school... I don't think I learned it until Discrete Math, which IIRC was a > 2nd or 3rd year course at my college and only

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

On Oct 2, 2017, at 5:33 PM, Jordan Rose wrote: >> >> Don't you think this is not normal situation and actually there IMO can't be >> any reason to keep this bug-producing inconsistency in Swift? (especially >> given Swift 5 seems like is a last moment to fix this) > > I

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

again, i should reiterate, most users aren’t compiler engineers and so most people use access modifiers as a means of code organization. being able to diagnose when a “private” symbol is being referenced from somewhere it shouldn’t be is very important; the linking and mangling details should be

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

On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution wrote: >> Keep in mind that Swift already goes far above and beyond in terms of >> operators > Yep, that's is a large part of why I'm such a Swift fan :-D Fortunately, no one is seriously proposing a major

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

> 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, at 7:33 PM, Jordan Rose via

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

> On Oct 2, 2017, at 9:15 PM, Xiaodi Wu wrote: > > > On Mon, Oct 2, 2017 at 22:23 Slava Pestov > wrote: >> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu > > wrote: >> >> On Mon, Oct

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

On Oct 2, 2017, at 3:24 PM, Xiaodi Wu wrote: >> Especially if people want to use the character in question as both an >> identifier and an operator: We can make the character an identifier and its >> lookalike an operator (or the other way around). > > Off the top of my

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

> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution > wrote: > > If you tried hard enough, you could probably create a variable that looks > like it's shadowing one from an outer scope while it actually isn't, and use > the two to confuse readers. This

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

On Mon, Oct 2, 2017 at 23:11 David Sweeris wrote: > On Oct 2, 2017, at 7:57 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris wrote: > >> >> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution < >>

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

On Mon, Oct 2, 2017 at 22:23 Slava Pestov wrote: > On Oct 2, 2017, at 8:06 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov wrote: > >> >> On Oct 2, 2017, at 7:52 PM, Kelvin Ma wrote: >> >>

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

> On Oct 2, 2017, at 7:57 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris > wrote: > > On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution >

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

> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov > wrote: > >> On Oct 2, 2017, at 7:52 PM, Kelvin Ma > > wrote: >> >> Is

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

On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <

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

On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov wrote: > > On Oct 2, 2017, at 7:52 PM, Kelvin Ma wrote: > > Is this only a problem with fileprivate or does it extend to private > members too? I feel like this would be a very valuable feature to support. > >

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

On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris wrote: > > On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’m

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

> On Oct 2, 2017, at 7:52 PM, Kelvin Ma wrote: > > Is this only a problem with fileprivate or does it extend to private members > too? I feel like this would be a very valuable feature to support. Private members too. Consider this example, struct S { private func f()

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

Is this only a problem with fileprivate or does it extend to private members too? I feel like this would be a very valuable feature to support. On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov wrote: > It would be a trivial change to allow @_versioned on private and > fileprivate

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

It would be a trivial change to allow @_versioned on private and fileprivate declarations, but there are two pitfalls to keep in mind: - Private symbols are mangled with a ‘discriminator’ which is basically a hash of the file name. So now it would be part of the ABI, which seems fragile — you

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

Sent from my iPad > On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution >> wrote: >> >> On 01.10.2017 1:18, Chris Lattner wrote: On Sep 29, 2017,

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

> On Oct 2, 2017, at 6:52 PM, Tony Allevato via swift-evolution > wrote: > > Thanks for hoisting this out into its own thread, Jordan. I was hesitant to > elaborate more on another access level thread :) > > I think the change should absolutely be made. Even though

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

> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution >> wrote: >> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I >>

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

> On Oct 2, 2017, at 3:24 PM, Xiaodi Wu wrote: > >> On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris wrote: >> >>> On Oct 2, 2017, at 09:14, Xiaodi Wu wrote: >>> >>> What is your use case for this? >>> On Mon, Oct 2, 2017 at

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

Thanks for hoisting this out into its own thread, Jordan. I was hesitant to elaborate more on another access level thread :) I think the change should absolutely be made. Even though the "private" keyword occurs at the file level, the description of the feature in the Swift documentation simply

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

> On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez wrote: > >> >> On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution >> > wrote: >> >> >> >>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution

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

> On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution >> > wrote: >> >> On 01.10.2017 1:18, Chris Lattner wrote:

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

Sounds reasonable to me. On Mon, Oct 2, 2017 at 18:54 Taylor Swift wrote: > Right now @_versioned is only for internal declarations. We should have > something similar for private and fileprivate declarations. I think most > people use those modifiers for code

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

On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution < swift-evolution@swift.org> wrote: > I’m all for fixing pressing issues requested by Xiaodi, but beyond that I > request we give a little more thought to the long term direction. > > My 2¢ is I’ve been convinced that very few

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

Ethan- This is brilliant. I don’t know if it’s technically feasible, but this is how it *should be.* - Jonathan > On Oct 2, 2017, at 17:28, Ethan Tira-Thompson via swift-evolution > wrote: > > I’m all for fixing pressing issues requested by Xiaodi, but beyond that

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

> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution > wrote: > > On 01.10.2017 1:18, Chris Lattner wrote: >>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> Vladimir, I agree with you on that

Re: [swift-evolution] [Generics] [Pitch] Dependent Types

Yes. At least, that’s a really good way to implement it. On Mon, Oct 2, 2017 at 8:39 PM Taylor Swift wrote: > don’t we need something like this for Fixed Size Arrays™ too? > > On Mon, Oct 2, 2017 at 6:23 PM, Félix Fischer via swift-evolution < > swift-evolution@swift.org>

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

I’m all for fixing pressing issues requested by Xiaodi, but beyond that I request we give a little more thought to the long term direction. My 2¢ is I’ve been convinced that very few characters are “obviously” either a operator or identifier across all contexts where they might be used. Thus

Re: [swift-evolution] [Generics] [Pitch] Dependent Types

I rather suspect that we would be best served by starting with integer literals as the only accepted “values in generics”. This would let us define fixed-size arrays and matrices, the modular arithmetic types you describe, and several other mathematical entities. Nevin.

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

Right now @_versioned is only for internal declarations. We should have something similar for private and fileprivate declarations. I think most people use those modifiers for code organization, not binary resilience, so we would do well to make the two intents separate and explicit. On Mon, Oct

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

On Mon, Oct 2, 2017 at 17:41 Taylor Swift wrote: > I think we should try to separate visibility from access control. In other > words, the compiler should be able to see more than the user. I want to be > able to write private and internal code that cannot be called

Re: [swift-evolution] [Generics] [Pitch] Dependent Types

don’t we need something like this for Fixed Size Arrays™ too? On Mon, Oct 2, 2017 at 6:23 PM, Félix Fischer via swift-evolution < swift-evolution@swift.org> wrote: > Hi swift-evolution, > > I’ve been thinking for the past months of making math libraries that could > benefit from a dependent

[swift-evolution] [Generics] [Pitch] Dependent Types

Hi swift-evolution, I’ve been thinking for the past months of making math libraries that could benefit from a dependent types system (see the Wikipedia article: https://en.wikipedia.org/wiki/Dependent_type?wprov=sfti1). Dependent types would allow for the type system to enforce certain

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

This is something I’ve been waiting for for a long time and I’m glad this is finally becoming a reality. This is a big step forward for anyone interested in seeing Swift get core “almost-stdlib” libraries. On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution <

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

I think we should try to separate visibility from access control. In other words, the compiler should be able to see more than the user. I want to be able to write private and internal code that cannot be called explicitly in source, but can still be inlined by the compiler. Right now people are

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

On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris wrote: > > On Oct 2, 2017, at 09:14, Xiaodi Wu wrote: > > What is your use case for this? > > On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On

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

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 public ABI, not necessarily inlinable, just as public things need only be public and not necessarily

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

On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov wrote: > Thanks for taking a look! > > > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > > 3. Even though @inlinable will have no effect on declarations which are > not public, we

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

> On Oct 2, 2017, at 2:20 PM, Greg Parker wrote: > > >> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution >> > wrote: >> inlinable declarations can only reference other public declarations. This is >>

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

Thanks for taking a look! > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky > wrote: > > I am hugely in favor of an @inlinable attribute, and I look forward to its > arrival with relish! > > Some feedback: > > 1. I think “inlinable” is the right

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

> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution > wrote: > inlinable declarations can only reference other public declarations. This is > because they can be emitted into the client binary, and are therefore limited > to referencing symbols that the

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

I am hugely in favor of an @inlinable attribute, and I look forward to its arrival with relish! Some feedback: 1. I think “inlinable” is the right spelling: it indicates that something is *able* to be inlined. 2. If I want to pass an @inlinable function as an argument (say, to map or filter)

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

Today's @available can't be the thing that makes symbols public, since it's also used to affect the availability context for private symbols. The one described in the library evolution document is specifically about marking something available with respect to the current module. So we would

Re: [swift-evolution] Enums and Source Compatibility

I don't think I have anything to say on this topic that I haven't already said: - Switching exhaustively over non-exhaustive enums is uncommon. - It's more important for a library to build without errors when its dependencies change than it is to get an error. (This doesn't apply to warnings,

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

Thanks for taking a look. @_versioned is not something we want to keep in the long term. The original idea was to allow @available annotations to be put on internal declarations, which would have the effect of giving their symbols public linkage. I think a follow-up proposal could introduce

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

Very much looking forward to this. Any possibility of rolling in some version (ha) of @_versioned so that @inlinable functions can reference internal declarations? On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > Hi all, > > Here is a draft

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

Hi all, Here is a draft proposal that makes public a feature we’ve had for a while. Let me know what you think! Cross-module inlining and specialization ("@inlinable") Proposal: SE- Authors: Slava Pestov , Jordan Rose Review

Re: [swift-evolution] Enums and Source Compatibility

This exists, but it's imperfect: it's possible that an app and its embedded frameworks are not all linked against the same version of the SDK, and then the system framework has to go with whatever the app does. (It's more important to behave consistently within a process.) It's not impossible

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

On Oct 2, 2017, at 09:14, Xiaodi Wu > wrote: > What is your use case for this? > > On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution > > wrote: > > On Oct 1, 2017, at

Re: [swift-evolution] Enums and Source Compatibility

> On Oct 2, 2017, at 11:29 AM, Wallacy via swift-evolution > wrote: > > @Slava > > If my understanding is correct. If I compile my application with the x.y.z > version of a Apple System Framework (like Cocoa). And this framework is > updated, several calls from

Re: [swift-evolution] Enums and Source Compatibility

@Slava If my understanding is correct. If I compile my application with the x.y.z version of a Apple System Framework (like Cocoa). And this framework is updated, several calls from my application to the "new" framework version x.z.a behave like in the x.y.z version for compatibility issues

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

What is your use case for this? On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Oct 1, 2017, at 9:26 PM, Kenny Leung via

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

> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution > wrote: > > >> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution >> wrote: >> >> Hi All. >> >> I’d like to help as well. I have fun with operators. >> >> There

Re: [swift-evolution] Enums and Source Compatibility

+1 for everything Vladimir says - which is why I'm pushing for switch! (just like try!, etc.) which would preserve current behavior. > On Oct 2, 2017, at 5:25 PM, Vladimir.S via swift-evolution > wrote: > > > Sorry to bother, but I still can't understand how the

Re: [swift-evolution] Enums and Source Compatibility

Sorry to bother, but I still can't understand how the proposed change *without* a 'future' case in switch will change our life and what would be our steps to support our code and to not make our code buggy. If I misunderstand something - sorry, please point me on this and I hope this also

Re: [swift-evolution] Re-pitch: remove(where:)

On 01.10.2017 22:44, Thorsten Seitz via swift-evolution wrote: `formFilter` strongly implies that the result is a filter, so this would be a very bad choice. i do not follow the argument that it makes sense to just concatenate `form` and the non-mutating method name. The precedence set by

Re: [swift-evolution] What's the Pages/Numbers/Keynote file's UTI in Drop

Thank u for ur reply Alex. Sorry for the wrong topic. So I posted my problem on apple forums. https://forums.developer.apple.com/message/266174#266174 Alex Blewitt 于2017年10月2日周一 下午6:24写道： > This isn't an appropriate question for the swift-evolution list. You might > like to ask

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

On 02.10.2017 8:30, Kenny Leung via swift-evolution wrote: I guess theoretically you could have two variables that look alike, but are actually different values, allowing you to insert some obfuscated malicious code somehow. Also, IIRC, there is a "similar" problem exists with Right-To-Left

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

This is why I’m advocating for the sections of the previous draft that deal with this issue to be maintained going forward. In that document and in the links provided in that document, there are very extensive previous discussions on lookalike characters and invisibles. No need to rehash this

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

> On 29. Sep 2017, at 02:59, Andrew Trick via swift-evolution > wrote: > > >> On Sep 6, 2017, at 10:15 PM, Taylor Swift > > wrote: >> >> okay so I think so far what’s been agreed on is >> >> 1. rename “Bytes”

Re: [swift-evolution] Idea: Public Access Modifier Respected in Type Definition

On 01.10.2017 1:18, Chris Lattner wrote: On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution wrote: Vladimir, I agree with you on that change, but it’s a separate topic from this one. Tony is absolutely correct that this topic has already been discussed.

Re: [swift-evolution] What's the Pages/Numbers/Keynote file's UTI in Drop

This isn't an appropriate question for the swift-evolution list. You might like to ask it on one of the Apple developer forums at https://forums.developer.apple.com Alex > On 2 Oct 2017, at 08:23, Yun Zeng via swift-evolution > wrote: > > Hi everyone, > Recently

[swift-evolution] Swift and actors

Hi everybody, Sadly I don’t have the time to participate on all the so interesting discussion about concurrency and actor stuff. But I have a question. I am working for 6 months in the Scala/Akka world, on a project (server stuff in a docker kubernates world) and after six months of work,

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

If you tried hard enough, you could probably create a variable that looks like it's shadowing one from an outer scope while it actually isn't, and use the two to confuse readers. This could trick people into thinking that some dangerous/backdoor code is actually good and safe, especially in the

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

> On 2 Oct 2017, at 06:39, Ted Kremenek via swift-evolution > wrote: > > >> On Oct 1, 2017, at 4:00 AM, Haravikk via swift-evolution >> > wrote: >> >>> >>> On 14 Sep 2017, at 20:10, Ben Rimmington

[swift-evolution] What's the Pages/Numbers/Keynote file's UTI in Drop

Hi everyone, Recently I am developing Drag function on iPad and met a problem: I can not get Pages/Numbers/Keynote files from performDrop in UIDropInteractionDelegate. Here is my solution: 1. Create my own file item provider, follow the protocol NSItemProviderReading. 2. *override method