Re: [swift-dev] State of String: Ergonomics, and You!

> On Jan 13, 2018, at 10:30 AM, Michael Ilseman via swift-dev > wrote: >> I wouldn’t overly rely on it for guidance on these issues give that it it >> stuck so squarely in the realm of UTF16. >> > > Wading a little into the weeds here, CharacterSet’s builtins model older

Re: [swift-dev] State of String: Ergonomics, and You!

On Jan 10, 2018, at 11:55 AM, Michael Ilseman via swift-dev wrote: > ## String Ergonomics > > Ergonomics is an area that’s not been well-served by String. Collection > conformance and multi-line literals in Swift 4 were a welcome first step. > But, trying to write a

Re: [swift-dev] State of String: ABI & Performance

On Jan 11, 2018, at 12:32 PM, Michael Ilseman wrote: >>> We may also want a compact 5-bit encoding for formatted numbers, such as >>> 64-bit memory addresses in hex, `Int.max` in base-10, and `Double` in >>> base-10, which would require 18, 19, and 24 characters

Re: [swift-dev] State of String: ABI & Performance

On Jan 10, 2018, at 11:55 AM, Michael Ilseman via swift-dev wrote: > (A gist-formatted version of this email can be found at > https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f > ) I’m very

Re: [swift-dev] "Swift 4.1 or Swift 3.3"

On Jan 8, 2018, at 5:26 PM, Jordan Rose via swift-dev wrote: >> On Jan 8, 2018, at 17:18, Chris Lattner > > wrote: >>> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev >>

Re: [swift-dev] "Swift 4.1 or Swift 3.3"

> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev > wrote: > > Hi, all. Swift 4.1 is off on its own branch and going well, but we never > quite came up with an answer for a particular problem developers might have: > "am I running a Swift 4.1 compiler?”. I agree,

Re: [swift-dev] "available externally" vs build time

> On Jan 4, 2018, at 2:11 PM, Erik Eckstein via swift-dev > wrote: > >>> >>> Well, with our pass pipeline architecture I suspect it will not make a >>> difference. We process functions bottom-up. For example, the performance >>> inliner optimizes the callee first before

Re: [swift-dev] "available externally" vs build time

> On Jan 4, 2018, at 1:08 PM, Erik Eckstein wrote: >>> 1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: >>> it deserializes the referenced function (MandatoryInlining.cpp:384) and >>> *then* checks to see if the callee is @_transparent. Would it

[swift-dev] "available externally" vs build time

Folks working on the SIL optimizer, particularly those interested in faster builds: If I understand the SIL optimizer correctly, it seems that when the current program references an external symbol declared as @_inlinable, that SILModule::linkFunction eagerly deserializes the @_inlinable body

Re: [swift-dev] [arc optimization] Why doesn't enum destructuring use guaranteed references?

This is a great question, I’m not sure what the answer is: maybe it is a simple case missed by the arc optimizer? -Chris > On Dec 27, 2017, at 9:19 PM, Félix Cloutier via swift-evolution > wrote: > > Running this on my MBP with 10 as the parameter: >

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #2101

This isn’t related to my patch. Artem? -Chris > On Dec 21, 2017, at 5:18 PM, swift...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2101] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2101/ >

Re: [swift-dev] Default deployment target for swiftc

+1 -Chris > On Nov 28, 2017, at 10:36 AM, Tony Allevato via swift-dev > wrote: > > I agree, the currently running OS seems like the right default here. > Progressive disclosure and ease of prototyping are good motivations here. If > I just want to quickly prototype

Re: [swift-dev] [Swift CI] Build Failure: 2. Swift Source Compatibility Suite (master) #806

Not it: -Chris In file included from /Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/swift/lib/Migrator/Migrator.cpp:13: In file included from /Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/swift/include/swift/Frontend/Frontend.h:35: In

Re: [swift-dev] deprecating -Ounchecked

On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev wrote: >>> >>> Deprecating would mean that we map -Ounchecked to -O. >>> >>> If you have any comments or concerns, please let me know >> >> What’s the motivation for this? What problem does it solve? > > There are

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Nov 1, 2017, at 9:16 AM, Ben Cohen via swift-dev <swift-dev@swift.org> > wrote: > > > >> On Oct 31, 2017, at 10:11 PM, Chris Lattner via swift-dev >> <swift-dev@swift.org> wrote: >> >> On Oct 31, 2017, at 9:07 AM, Stephen

Re: [swift-dev] deprecating -Ounchecked

> On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev > wrote: > > Hi, > > I’d like to propose to deprecate the -Ounchecked swift optimization mode. > > The -Ounchecked mode actually contradicts one of the main goals of swift: to > be a safe language. > In the past

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

On Oct 31, 2017, at 9:07 AM, Stephen Canon via swift-dev wrote: > [Replying to the thread as a whole] > > There have been a bunch of suggestions for variants of `==` that either trap > on NaN or return `Bool?`. I think that these suggestions result from people > getting

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 11:44 PM, Xiaodi Wu via swift-dev > wrote: > > On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull > wrote: > One completely different idea, which I brought up a year or so ago, is to do > what we do with pointers

Re: [swift-dev] sharing tips and tricks and scripts

Any scripts should be subject to the same code review and design policies as the rest of the compiler. A bisection script or build-script seem fine, but a four line script to automate something is probably not the right thing to include. -Chris > On Oct 17, 2017, at 6:05 PM, Jordan Rose via

Re: [swift-dev] Reducing array abstraction

> On Oct 10, 2017, at 9:50 AM, Erik Eckstein wrote: > > > >> On Oct 9, 2017, at 9:46 PM, Chris Lattner > > wrote: >> >> On Oct 8, 2017, at 3:30 PM, Erik Eckstein > >

Re: [swift-dev] Reducing array abstraction

On Oct 9, 2017, at 9:55 PM, Slava Pestov via swift-dev wrote: >> On Oct 7, 2017, at 2:01 PM, Chris Lattner wrote: >> Right. If we ignore source compatibility for the moment, it seems clear >> that the best callee side representation for varargs is a

Re: [swift-dev] Reducing array abstraction

On Oct 8, 2017, at 3:30 PM, Erik Eckstein wrote: >>> We definitely already have a heap->stack for classes in the guise of the >>> StackPromotion optimization is that what you are talking about with the >>> "array outlining" optimization? (outlining to me is referring to

Re: [swift-dev] Reducing array abstraction

> On Oct 8, 2017, at 11:57 AM, Michael Gottesman via swift-dev > <swift-dev@swift.org> wrote: > > >> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev >> <swift-dev@swift.org> wrote: >> >> This question is somewhere between swift-dev

Re: [swift-dev] Reducing array abstraction

On Oct 6, 2017, at 11:12 PM, Slava Pestov <spes...@apple.com> wrote: >> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev >> <swift-dev@swift.org> wrote: >> This question is somewhere between swift-dev and swift-users, not sure where >> best to post thi

[swift-dev] Reducing array abstraction

This question is somewhere between swift-dev and swift-users, not sure where best to post this. I’m working on a project that wants to get very low-abstraction penalty array operations, particularly with varargs. Given the currently language limitations (no fixed size arrays), the best I’ve

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

> On Jul 29, 2017, at 1:32 PM, John McCall <rjmcc...@apple.com> wrote: > >> On Jul 29, 2017, at 4:24 PM, Chris Lattner via swift-dev >> <swift-dev@swift.org> wrote: >> >> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev <swift-dev@swift.o

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev wrote: > > Overall, my intuition is that the tradeoffs come out in favor for nonunique > metadata objects, but what do you all think? Is there anything I'm missing? I think your proposal makes sense, particularly when

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

> On Jul 28, 2017, at 3:59 PM, Jordan Rose via swift-dev > wrote: > >>> So generic code to instantiate type metadata would have to construct these >>> mangled strings eagerly? >> >> We already do exactly that for the ObjC runtime name of generic class >> instantiations,

Re: [swift-dev] [Discuss] Remove SwiftExperimental

> On Jul 21, 2017, at 8:57 AM, Joe Groff <jgr...@apple.com> wrote: > > > > On Jul 20, 2017, at 12:54 PM, Chris Lattner via swift-dev > <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: > >> >>> On Jul 19, 2017, at 1:23 PM,

Re: [swift-dev] Proposal: Opaque SIL values

On Jan 24, 2017, at 10:58 PM, Andrew Trick wrote: > > That would come about when the program wants to use the same lvalue for > multiple real values. I don't expect many problems with simple opaque types. > The only way to mutate them is either passing them @inout or

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev > wrote: > > I’m sending out a proposal for fundamentally changing SIL. This work feeds > into generic code optimization, resilience, semantic ARC, and SIL ownership. > This was discussed at length back in

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 20, 2016, at 2:59 PM, Joe Groff via swift-dev > wrote: >> >> copysign( ) is a reason to not pick the first option. I’m not very worried >> about it, but it is a reason. I see no problem with the second option. > > As we discussed in person this morning,

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

On Oct 11, 2016, at 10:10 AM, Michael Gottesman wrote: >> >If ARC Code Motion wishes to move the ARC semantics of ownership qualified >> >load, store instructions, it must now consider read/write effects. On the >> >other hand, it will be able to now not consider the

Re: [swift-dev] What about concurrency?

On Sep 4, 2016, at 3:00 PM, Anton Mironov via swift-dev wrote: > > My job is mostly consists of writing core functionality for macOS (and I love > core functionality). My code must take advantage of concurrency. I've been > looking for solutions that allow me to write

Re: [swift-dev] Question about size of Character type

> On Aug 19, 2016, at 6:22 PM, Slava Pestov via swift-dev > wrote: > > >> On Aug 19, 2016, at 2:04 PM, Jordan Rose via swift-dev > > wrote: >> >> We have an old Radar about this, rdar://problem/16754935 >> . It's

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #6656

Fixed in 156b9bb -Chris > On Jul 31, 2016, at 5:27 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#6656] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6656/ >

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #7028

Fixing. Validation tests shouldn’t check diagnostics. -Chris > On Jul 31, 2016, at 4:47 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7028] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7028/ >

Re: [swift-dev] [swift-evolution] [Swift 4] Organizing source stability

> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch wrote: > > Here are a few thoughts: > -swift=4 > -swift-version=4 -swift-version seems like the best option to me, but Jordan will have a strong opinion. I think he’s crazy busy with Swift 3 work until late next week.

Re: [swift-dev] [swift-evolution] [Swift 4] Organizing source stability

> On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Chris writes: > - Source stability features: These should be relatively small, but important. > For example, we need a “-std=swift3” sort of compiler flag. We may also add > a way

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - OS X (master) #5601

Not mine, -Chris > On Jul 29, 2016, at 4:59 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-osx [#5601] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5601/ > >

Re: [swift-dev] [swift-evolution] End of source-breaking changes for Swift 3

> On Jul 27, 2016, at 12:45 PM, Slava Pestov via swift-evolution > wrote: > > >> On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev >> > wrote: >> >> >> SE-0092 - Typealiases in protocols and protocol

Re: [swift-dev] [Swift Code Owners] new code owner for the SIL optimizer

> On Jul 22, 2016, at 3:59 PM, Bob Wilson wrote: > > CODE_OWNERS.TXT still shows Nadav as the owner of the SIL optimizer, even > though he is no longer working on Swift. We should have a new code owner, and > I would like to nominate Erik Eckstein. There are a lot of

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #6763

Not really sure what is going on here, but this isn’t due to my patch afaict. -Chris > On Jul 23, 2016, at 5:55 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6763] > > Build URL: >

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #6305

Fixed in b4cba58. -Chris > On Jul 17, 2016, at 3:40 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#6305] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6305/ >

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #6558

Fixed harder in 0296316. -Chris > On Jul 17, 2016, at 12:59 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6558] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6558/ >

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #6172

Should be fixed in 87db7b4. -Chris > On Jul 2, 2016, at 4:50 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6172] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6172/ >

Re: [swift-dev] [swift-evolution] Possible bug with arithmetic optional comparison ?

> On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev > wrote: > > I wouldn’t phrase it this way. “nil” could just as easily been above all of > the integers. > > We added overloads for < and friends that took optionals so that you could > sort an array by passing <

Re: [swift-dev] What do to when stdlib guidelines conflict with proposal?

On May 11, 2016, at 8:17 PM, Russ Bishop via swift-dev wrote: > >> On May 11, 2016, at 4:50 PM, Dmitri Gribenko wrote: >> >> On Wed, May 11, 2016 at 2:53 PM, Russ Bishop via swift-dev >> wrote: >>> I’m implementing SE-0017 but

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (master) #3898

Fixed in 684e660. -Chris > On May 6, 2016, at 9:30 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#3898] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/3898/ > > Project:

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #4716

Fixed in 7035da2. -Chris > On May 2, 2016, at 9:39 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#4716] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4716/ >

Re: [swift-dev] Lazy var and deinit

> On Apr 21, 2016, at 2:29 AM, Alexandr.moq via swift-dev > wrote: > > Should SWIFT initialize a variable in deinit method if it has not been > initialized? > > For example: > ```swift > class A { > lazy var b = B() > deinit { > b.clean() >

Re: [swift-dev] Swift port to Windows : Offering help!

On Apr 20, 2016, at 10:59 PM, Joel Van Eenwyk via swift-dev wrote: > Hi all, > > I'm a very new user of Swift and interested in finding ways to contribute to > the project. I can happily work with the Linux port of the project, but I > have a lot of Windows development

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (master) #1018

Fixed with 3aa4ff4. -Chris > On Apr 17, 2016, at 12:16 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1018] > > Build URL: > https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1018/ >

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (master) #2761

IMO, we should remove/disable this test unless it can be “really” fixed. It is unacceptable to have a test that we know injects noise into our CI systems. Having to second guess whether failures are “real” or not undermines their value, and we should continue to stomp out any nondeterminism

[swift-dev] FYI: Apple holiday shutdown

Hi Everyone, Just a head’s up that Apple has a holiday shutdown from Dec 24 to Jan 3 (and many people are already out). The web site, mailing lists and all other services should still be up, but don’t be surprised if there are additional delays in responding to threads and pull requests

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

> On Dec 20, 2015, at 9:53 PM, Dmitri Gribenko via swift-dev > wrote: > >> >> nm -a libswiftCore.dylib > strings.txt >> >> I also have a concern about making mangled names completely unreadable. >> Today, I can frequently at least get a gist of what the referenced entity

Re: [swift-dev] Including third-party code in repo

On Dec 19, 2015, at 12:26 PM, Zhuowei Z via swift-dev wrote: > I'm currently working on a port of Swift to Android. Great! > Since Android's libc is missing a few required methods, I added code from a > few other sources to implement the functionality. Specifically, I

Re: [swift-dev] Starter project: SR-2: Build configuration directives can not wrap switch cases

On Dec 17, 2015, at 9:06 AM, Dmitri Gribenko via swift-dev wrote: >> Quick question about this one. >> >> As mentioned in SR-2, the current grammar for switch >> statements [1] does not allow for compiler control >> statements. So, fixing this involves a grammar >> change.

Re: [swift-dev] Breaking change in lexing operators next to comments

ft-evolution. I tend to agree with your argument that treating them as whitespace is better, but I don’t feel strongly about it. -Chris > >> On Dec 15, 2015, at 7:15 PM, Jesse Rusak <m...@jesserusak.com >> <mailto:m...@jesserusak.com>> wrote: >> >>

Re: [swift-dev] Starter project: SR-2: Build configuration directives can not wrap switch cases

On Dec 17, 2015, at 10:19 AM, Meador Inge wrote: > >> I suspect that grammar changes will require a proposal > >> on the swift-evo list? > > > > I think this can be treated as a bug fix. > > Agreed, > > Thanks. What is the process for updating the grammar > in the

Re: [swift-dev] This little program currently compiles fine, but should it?

> On Dec 15, 2015, at 3:42 PM, Jens Persson via swift-dev > wrote: > > Ok thanks, and what about the initial topic of this thread, ie stuff like > this: > > func f() { > 1; "two"; 3.0 > [4, 5]; 6 * 7 > print("No warnings or errors!") > } > f() // No warnings

Re: [swift-dev] Location of "indirect" declaration modifier

On Dec 11, 2015, at 7:03 AM, Slava Pestov via swift-dev wrote: > With your proposal, the fact that the entire tuple payload can be matched by > a pattern implies that ‘indirect’ has to become a formal type in the > language, since you will now be able to write down a value

Re: [swift-dev] Porting swift to FreeBSD

> On Dec 13, 2015, at 3:34 AM, Davide Italiano via swift-dev > wrote: > > On Sun, Dec 13, 2015 at 6:15 AM, Dmitri Gribenko wrote: >> On Sun, Dec 13, 2015 at 2:52 AM, Davide Italiano >> wrote: >>> And now, swift compiled

Re: [swift-dev] Radar and bugs.swift.org

> On Dec 9, 2015, at 5:21 PM, Frederick Kellison-Linn via swift-dev > wrote: > > Hi everyone, > > All throughout the Swift codebase there references to Radar bugs (just do a > search for “rdar" on the repo). As far as I am aware, these are all still > private/internal.

Re: [swift-dev] Language Specification on Github?

> On Dec 4, 2015, at 8:23 AM, David Waite wrote: > > Is there a possibility of the swift books (at least the core language and a > html build process ) being turned into projects on github? I do have > changes/fixes which I would suggest against the books if