Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

aren’t there other benefits to dynamic linking though? i’m not arguing against dynamic linking, i’m arguing that functions that should be part of ABI should *always* be called through the entry point and functions that can be emitted into the client should *never* be called through the entry

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Sure, users download new apps more often than they download new OSes, but you’re basically arguing against dynamic linking at this point. If everything was statically linked, vendors would not be able to ship security updates, etc. Slava > On Dec 24, 2017, at 8:46 PM, Kelvin Ma

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 24, 2017, at 8:33 PM, Howard Lovatt wrote: > > I was making two seperate points: 1. Annotating which parts of a public APIs > are stable should not be necessary and 2. Inlining should be left to the > compiler. > > Point 1: If you had a module system that

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

in theory this could happen but if you ask me this is such an exceedingly rare case that i don’t count much net benefit from it. most ithing users (that i know) avoid ios updates like hell but have automatic app updates turned on. so 99% of the time i would expect the app version to be more recent

Re: [swift-evolution] namespacing protocols to other types

vv On Sun, Dec 24, 2017 at 11:36 PM, Howard Lovatt wrote: > I would say yes they are different for the example. Definitely something I > miss is nesting types to given a seperate namespace. > > -- Howard. > > > On 24 Dec 2017, at 9:56 pm, Slava Pestov via

Re: [swift-evolution] namespacing protocols to other types

I would say yes they are different for the example. Definitely something I miss is nesting types to given a seperate namespace. -- Howard. > On 24 Dec 2017, at 9:56 pm, Slava Pestov via swift-evolution > wrote: > > There was a proposal to allow protocols to be

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

I was making two seperate points: 1. Annotating which parts of a public APIs are stable should not be necessary and 2. Inlining should be left to the compiler. Point 1: If you had a module system that was versioned then a public declaration should be taken as stable across all minor releases.

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution > wrote: > > why can’t we just remove inlineable functions from ABI altogether? if the > argument is that app code won’t be able to take advantage of improved > implementations in future library versions

Re: [swift-evolution] namespacing protocols to other types

There was a proposal to allow protocols to be nested inside types at one point but it didn’t move forward. Basically, if the outer type is a non-generic class, struct or enum, there’s no conceptual difficulty at all. If the outer type is a generic type or another protocol, you have a problem

[swift-evolution] namespacing protocols to other types

is there a reason why it’s not allowed to nest a protocol declaration inside another type? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 24, 2017, at 3:04 PM, Howard Lovatt via swift-evolution > wrote: > > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md > >

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

why can’t we just remove inlineable functions from ABI altogether? if the argument is that app code won’t be able to take advantage of improved implementations in future library versions i don’t think that makes sense at all i would assume client code gets recompiled much more often than library

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md What is your evaluation of the proposal? -1 The proposal puts all the emphasis on the programmer. It is better for the compiler to decide if something is to be