Re: [swift-dev] [stdlib] Array.description calls debugDescription on its contents

when you print an array of strings you want the strings quoted, and to get the quoted representation of the elements when they are strings you need String(reflecting: arrayElement), not String(arrayElement). > > -Wojtek > >> Wiadomość napisana przez Dave Abrahams via swift-de

Re: [swift-dev] [stdlib] Array.description calls debugDescription on its contents

> On Dec 13, 2015, at 11:08 PM, Dave Abrahams via swift-dev > wrote: > >> >> On Dec 13, 2015, at 12:43 PM, Wojciech Czekalski > <mailto:wczekal...@me.com>> wrote: >> >> I agree with Brent that offering description on Arrays where it "should

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

> On Dec 14, 2015, at 11:04 AM, Jens Persson via swift-dev > wrote: > > Yes, and I don't know if there is any particular reason why the == operator > for Int doesn't have @warn_unused_result while the one for Doubles has: > > func f() { 1 == 2 } // OK > func g() { 1.0 == 2.0 } // Warning: Res

Re: [swift-dev] `withUnsafePointer` mutates `self`

> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev > wrote: > > On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote: >> >> Yeah, it seems to me like a reasonable refinement for 'withUnsafePointer' to >> take an immutable parameter. Since this is a stdlib API change, you s

Re: [swift-dev] `withUnsafePointer` mutates `self`

> On Dec 15, 2015, at 6:46 PM, Kevin Ballard wrote: > > On Tue, Dec 15, 2015, at 06:39 PM, Dave Abrahams wrote: >> >>> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev >>> wrote: >>> >>> On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote: Yeah, it seems to me

Re: [swift-dev] `withUnsafePointer` mutates `self`

> On Dec 15, 2015, at 11:51 PM, Kevin Ballard wrote: > > On Tue, Dec 15, 2015, at 11:25 PM, Dave Abrahams wrote: >> >>> On Dec 15, 2015, at 6:46 PM, Kevin Ballard wrote: >>> >>> On Tue, Dec 15, 2015, at 06:39 PM, Dave Abrahams wrote: > On Dec 15, 2015, at 6:33 PM, Kevin Ballard via

Re: [swift-dev] `withUnsafePointer` mutates `self`

> On Dec 16, 2015, at 6:59 AM, Ryan Lovelett via swift-dev > wrote: > > On Wed, Dec 16, 2015, at 03:12 AM, Dave Abrahams via swift-dev wrote: >> >>> On Dec 15, 2015, at 11:51 PM, Kevin Ballard wrote: >>> >>> On Tue, Dec 15, 2015, at 11:25 PM, Dav

Re: [swift-dev] inout and aliasing in the optimizer

Sent from my moss-covered three-handled family gradunza > On Dec 17, 2015, at 4:52 PM, Jordan Rose via swift-dev > wrote: > > >>> On Dec 17, 2015, at 14:48, Joe Groff via swift-dev >>> wrote: >>> >>> >>> On Dec 17, 2015, at 2:34 PM, Erik Eckstein via swift-dev >>> wrote: >>> >>> Hi, >

Re: [swift-dev] metatype of Int

> On Dec 18, 2015, at 11:16 AM, Rafkind, Jon via swift-dev > wrote: > > Given a swift::MetaType how can I tell if it corresponds to the MetaType of > the standard Int type? Is there a way to get a reference to the MetaType from > the StdlibModule or TheBuiltinModule? > > For now I can conver

Re: [swift-dev] C-style For Loops

> On Dec 19, 2015, at 11:44 AM, Donnacha Oisín Kidney via swift-dev > wrote: > > You can define an extension on interval types: > > extension HalfOpenInterval where Bound: Strideable { > func by(n: Bound.Stride) -> StrideTo { > return start.stride(to: end, by: n) > } > } > > extension

Re: [swift-dev] C-style For Loops

most of what you're saying here, or why you're saying it. The extensions as shown in Donnacha's post work for me. > > Em sáb, 19 de dez de 2015 às 18:39, Dave Abrahams via swift-dev > mailto:swift-dev@swift.org>> escreveu: >> On Dec 19, 2015, at 11:44

Re: [swift-dev] C-style For Loops

> On Dec 19, 2015, at 1:47 PM, Brent Royal-Gordon > wrote: > >>> for lat in (CGFloat(-60)...60).by(30) { >>> print(lat) >>> } >>> >>> for lat in (CGFloat(-60)..<60).by(30) { >>> print(lat) >>> } >> >> This is nice; why don't we put it in the standard library and get rid of the >> "stride"

Re: [swift-dev] C-style For Loops

> On Dec 19, 2015, at 2:24 PM, Brent Royal-Gordon > wrote: > >>> One practical reason is that interval.start must always be before >>> interval.end, so this makes striding in reverse difficult. >> >> We could declare that negative strides cause us to start at the end rather >> than at the st

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

> On Dec 30, 2015, at 4:50 PM, Kevin Ballard via swift-dev > wrote: > > FWIW, once we have conditional protocol conformance (`extension ... : Proto > where ...`), and if we get rid of the circular protocol inheritance > limitation (two protocols that inherit from each other, which should in >

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

-Dave > On Dec 31, 2015, at 1:11 AM, Kevin Ballard wrote: > > On Dec 31, 2015, at 1:07 AM, Dave Abrahams wrote: > >>> Alternatively, we could work around it by allowing you to say `extension >>> Any : EquatableSequenceType where Self : SequenceType { ... }` and having >>> that essentially e

Re: [swift-dev] changes in the inliner

on Fri Apr 01 2016, Erik Eckstein wrote: > Hi, > > I'd like to give some more information about the inliner changes I landed > this week. > > The goal was to restrict inlining to improve code size while not degrade > performance (too much). > This was mainly achieved by improving the heuristic

[swift-dev] Why are we re-linking?

Can anyone explain why we're re-linking all these C++ executables when I make changes only to the standard library? [5/130] Linking CXX static library lib/libswiftBasic.a [6/130] Linking CXX shared library lib/libswiftDemangle.dylib [7/130] Linking CXX executable bin/swift [8/130] Linking CXX exe

Re: [swift-dev] Why are we re-linking?

on Fri Apr 08 2016, Chris Bieneman wrote: > In Clang this is handled by having a CMake option control whether or > not the SCM revision is embedded in the binary > (CLANG_APPEND_VC_REV). Clang defaults the option to 'Off' so that > engineering workflows don't need to override it, but it is frequ

Re: [swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

on Sun Apr 10 2016, Austin Zheng wrote: > I'm really sorry for dropping the ball and disappearing off the list. I'd like > to help out if I can. I'll check out the current branch tomorrow and see what > the status of the work is, but let me know if everything is done > already/there's > somethi

Re: [swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

on Mon Apr 11 2016, Shawn Erickson wrote: > Anything to attempt on strings? I see you are considering consolidating down > to > a single index type for those, etc. Of course you also imply a large string > rework that may happen in the future. Yes, Strings need the same treatment (though it ma

Re: [swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

on Mon Apr 11 2016, Dmitri Gribenko wrote: > On Mon, Apr 11, 2016 at 11:07 AM, Dave Abrahams wrote: >> >> on Sun Apr 10 2016, Austin Zheng wrote: >> >>> I'm really sorry for dropping the ball and disappearing off the list. I'd >>> like >>> to help out if I can. I'll check out the current bran

Re: [swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

on Mon Apr 11 2016, Shawn Erickson wrote: > On Mon, Apr 11, 2016 at 11:42 AM Dave Abrahams wrote: > > on Mon Apr 11 2016, Shawn Erickson wrote: > > > Anything to attempt on strings? I see you are considering consolidating > down to > > a single index type for those, etc. Of cou

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

My fault; I'm fixing this, sorry. on Mon May 02 2016, no-reply-AT-swift.org wrote: > Report > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#4698] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubunt > u-15_10/4698/

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

on Mon May 02 2016, Jordan Rose wrote: > Dave, I think this really is you, even if it's something the compiler should > accept. (I didn't look too closely.) I don't know what to do about it, but I'm investigating. > Jordan > > On May 2, 2016, at 12:47, no-re...@swift.org wrote: > > New

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

0e38795 should fix this (local testing confirms) on Mon May 02 2016, Jordan Rose wrote: > Dave, I think this really is you, even if it's something the compiler should > accept. (I didn't look too closely.) > > Jordan > > On May 2, 2016, at 12:47, no-re...@swift.org wrote: > > New issue

Re: [swift-dev] Endgame for Swift 3

on Fri Jul 15 2016, Dmitri Gribenko wrote: > On Fri, Jul 15, 2016 at 11:44 AM, Ted kremenek via swift-dev > wrote: >> Good question. >> >> Dave/Dmitri: do you have a recommendation here? I can see either the JIRA >> issues referencing the proposal (if one exists) or updating the gist. I >> pr

Re: [swift-dev] Turns out Incremental builds were not actually incremental

on Tue Jul 19 2016, Michael Gottesman wrote: > Given the backup in the CI, I started looking at what was going on > there and I found that the following incremental bots were actually > /NOT/ incremental: > > 1. OS X Swift incremental. > 2. 14.04 Linux Swift incremental. > 3. 15.10 Linux Swift i

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

on Wed Jul 27 2016, Ted Kremenek wrote: > - swift-evolution, swift-evolution-announce > > Dave/Max: can you speak this? >> On Jul 27, 2016, at 3:17 PM, Tony Allevato wrote: >> >> I noticed that while SE-0091 appears to be implemented (from a >> cursory glance at some of the affected types lik

[swift-dev] clang: warning: argument unused during compilation: '-MMD'

I'm seeing this warning a lot recently. Can we a) drop that argument b) add -Wno-unused-variable to the clang command line, or c) is there a better fix? -- Dave ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/

Re: [swift-dev] Failure in optimized tests

on Tue Aug 02 2016, Jordan Rose wrote: > I think this might be a real issue. Dave, what do you think? > > https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RD_test-simulator/1863/consoleFull#-1050474920fca400bf-2f4a-462e-b517-e058d770b2d7 > > Every “Minimal.*Collection” suite is failing on this

Re: [swift-dev] What exactly does it mean for a Swift pointer to be initialized?

on Fri Aug 05 2016, Jens Persson wrote: > I'm trying to understand the new Swift 3 (4?) pointer API and Swift's > memory model. > > More specifically, I'd like to know more about what exactly it means for a > pointer to be initialized or not. Sorry to pick nits, but... every pointer that exist

Re: [swift-dev] What exactly does it mean for a Swift pointer to be initialized?

on Fri Aug 05 2016, Andrew Trick wrote: >> On Aug 5, 2016, at 12:43 PM, Jens Persson wrote: >> >> I'm trying to understand the new Swift 3 (4?) pointer API and Swift's memory >> model. >> >> More specifically, I'd like to know more about what exactly it means > >> for a pointer to be initial

[swift-dev] linux long tests failing due to JUnit issue?

I don't really understand why JUnit would be relevant here, but we're getting this failure after everything else seems to pass. [xUnit] [INFO] - Processing JUnit [xUnit] [INFO] - [JUnit] - No test report file(s) were found with the pattern 'Ninja-ReleaseAssert/swift-linux-x86_64/swift-test-resul

Re: [swift-dev] undefined symbol: _TFC10Foundation8NSNumberg25customPlaygroundQuickLookOs19PlaygroundQuickLook

on Thu Aug 11 2016, Philippe Hausler wrote: > Looks like that is a dirty build. > > I think we should probably just delete the support in > swift-corelibs-foundation entirely for now until a stable interface > can be decided (and also delete the tests for them in > swift-corelibs-foundation). >

[swift-dev] Linux Foundation test failure

This appears to be due to some missing dependency information in the build system for Foundation's tests. Some stdlib names not used directly by the overlay or tests were changed and now linking fails with: + env LD_LIBRARY_PATH=//usr//lib/swift/:/home/buildnode/disk2/workspace/oss-swift-increm

Re: [swift-dev] Linux Foundation test failure

d a stale build around. Which points strongly toward "missing dependency information in the build system" as I noted, n'est-ce pas? >> On Aug 29, 2016, at 10:43 AM, Dave Abrahams via swift-dev >> wrote: >> >> >> This appears to be due to some missing de

Re: [swift-dev] Implementation of Type Erasers

on Tue Sep 06 2016, Chris Eidhof wrote: > Thanks! That explains a lot. > > In my version, performance only is improved by 10%, so I'm not sure if the > tradeoff is worth it: > > In the isolated case of AnyIterator, there's only one method, so the sizeof > is the same (and the performance is wort

Re: [swift-dev] 'SwiftShims': no such file or directory

on Mon Sep 19 2016, Eric Wing wrote: > On 9/19/16, Daniel Dunbar wrote: >> Are you building within a shared folder? We have heard reports of this >> happening in such an environment, but we don't have a handle on the exact >> steps to reproduce. Getting that information would be very useful. >>

Re: [swift-dev] 'SwiftShims': no such file or directory

on Mon Sep 19 2016, Eric Wing wrote: > I've been trying to build Swift for Linux with --installable-package > to build a swift-package.tar.gz that I can install to another Linux > machine. > > When I extract my package on the other machine, and try either > compiling a simple print("hello world"

Re: [swift-dev] The Legend of the Toll-Free Swift -> ObjC Collection Bridge

on Fri Oct 07 2016, Alexis wrote: > I’ve been looking a lot into how Swift and Objective C collections > inter-convert because a bunch of necessary cleanup for ABI stability > interacts with it. Unfortunately I’ve run into some conflicting > information with respect to how stuff should work, and

Re: [swift-dev] Dictionary Collision Resolution Guarantees

on Thu Oct 13 2016, Alexis wrote: > I’m currently cleaning up the docs on Dictionary to reflect the new indexing > model, and I stumbled > across the note that the following code should work assuming no reallocations > occur: > > // > // var (i, found) = d.find(k) // i is associated with d's

Re: [swift-dev] Dictionary Collision Resolution Guarantees

on Thu Oct 13 2016, Alexis wrote: >>> This is effectively assuming that the open-addressing scheme being >>> used is first-come-first-serve (FCFS). That is, any element being >>> inserted can *only* be inserted into vacant buckets, rather than >>> displacing existing elements. This is currently

Re: [swift-dev] Dictionary Collision Resolution Guarantees

on Fri Oct 14 2016, Ole Begemann wrote: > On 14/10/2016 02:46, Dave Abrahams wrote: > >>> OK cool, is there any reason it’s even written down? I don’t see any code >>> that’s obviously relying on it. (seems fine to delete it?) >> >> It's written down because we've never formalized our index inva

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

on Thu Oct 13 2016, Joe Groff wrote: >> On Oct 13, 2016, at 1:18 PM, Greg Parker wrote: >> >> >>> On Oct 13, 2016, at 10:46 AM, John McCall via swift-dev >>> wrote: >>> > On Oct 13, 2016, at 9:04 AM, Joe Groff via swift-dev wrote: > On Mar 1, 2016, at 1:33 PM, Joe Gro

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

on Tue Oct 11 2016, Joe Groff wrote: > I just tracked down a bug due to C++ code in the Swift runtime code > trying to interface with standard library code written in Swift, but > getting the ABI slightly wrong and leading to some nasty > hard-to-reproduce heisenbugs. While I've narrowed down th

Re: [swift-dev] copy-on-write proposal

on Tue Oct 11 2016, Erik Eckstein wrote: > This is a proposal for representing copy-on-write buffers in > SIL. Actually it’s still a draft for a proposal. It also heavily > depends on how we move forward with SIL ownership. > > :orphan: > > .. highlight:: sil > >

Re: [swift-dev] copy-on-write proposal

on Thu Oct 13 2016, Joe Groff wrote: >> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev >> wrote: >> >> This is a proposal for representing copy-on-write buffers in >> SIL. Actually it’s still a draft for a proposal. It also heavily >> depends on how we move forward with SIL ownershi

Re: [swift-dev] copy-on-write proposal

on Mon Oct 17 2016, Erik Eckstein wrote: > On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev > wrote: > >> on Thu Oct 13 2016, Joe Groff > <http://swift-dev-at-swift.org/>> wrote: >> >>>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

on Mon Oct 17 2016, Joe Groff wrote: >> On Oct 16, 2016, at 1:10 PM, Dave Abrahams via swift-dev >> wrote: >> >> >> on Thu Oct 13 2016, Joe Groff wrote: >> > >>>> On Oct 13, 2016, at 1:18 PM, Greg Parker wrote: >>>> >

[swift-dev] smoke test not very smoky?

I thought the smoke test was supposed to be a fairly quick test that just covered the basics, but it seems to be doing plenty of *really long* tests, for example: https://ci.swift.org/job/swift-PR-Linux-smoke-test/1916/console which has already been running for over 30 minutes. Am I missing somet

Re: [swift-dev] smoke test not very smoky?

2016, at 11:44 PM, mishal_shah wrote: > > >> On Oct 18, 2016, at 8:29 PM, Michael Gottesman wrote: >> >> >>> On Oct 18, 2016, at 6:40 PM, Dave Abrahams via swift-dev >>> wrote: >>> >>> >>> I thought the smoke test was suppos

Re: [swift-dev] smoke test not very smoky?

>>> On Oct 18, 2016, at 8:29 PM, Michael Gottesman wrote: >>> >>> >>>> On Oct 18, 2016, at 6:40 PM, Dave Abrahams via swift-dev >>>> wrote: >>>> >>>> >>>> I thought the smoke test was supposed to be a fairly

Re: [swift-dev] copy-on-write proposal

on Tue Oct 18 2016, Erik Eckstein wrote: >> On Oct 17, 2016, at 10:21 AM, Dave Abrahams wrote: >> >> >> on Mon Oct 17 2016, Erik Eckstein wrote: >> > >>> On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev >>> wrote: >>>

Re: [swift-dev] smoke test not very smoky?

on Wed Oct 19 2016, Jordan Rose wrote: >> On Oct 19, 2016, at 9:44, Dave Abrahams via swift-dev >> wrote: >> >> >> on Wed Oct 19 2016, Dave Abrahams > <http://swift-dev-at-swift.org/>> wrote: >> >>> It still seems like, for a smoke

Re: [swift-dev] copy-on-write proposal

ote: > > >>> On Oct 19, 2016, at 6:36 PM, Andrew Trick via swift-dev >>> wrote: >>> >>> >>> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev >>> wrote: >>> >>> >>> on Tue Oct 18

Re: [swift-dev] Cleaning up stale branches?

on Fri Oct 21 2016, Daniel Dunbar wrote: > While on this topic... > > GitHub's support for doing cross-repo pull requests is > excellent. Anyone can easily fork the main repo, and push to their > side repo (for example, with: `git push ddunbar > HEAD:name-of-my-new-branch`) and the GitHub web UI

Re: [swift-dev] Cleaning up stale branches?

on Fri Oct 21 2016, John McCall wrote: >> On Oct 21, 2016, at 10:39 AM, Dave Abrahams via swift-dev >> wrote: >> on Fri Oct 21 2016, Daniel Dunbar wrote: >> >>> While on this topic... >>> > >>> GitHub's support for doing cross-repo

Re: [swift-dev] Cleaning up stale branches?

on Fri Oct 21 2016, John McCall wrote: >> On Oct 21, 2016, at 12:23 PM, Daniel Dunbar wrote: >>> On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> >>> on Fri Oct 21

Re: [swift-dev] Cleaning up stale branches?

FWIW, I reviewed mine, and all the branches that are still in the repo are there for a good reason. Sent from my iPad > On Oct 21, 2016, at 9:20 PM, Ted kremenek wrote: > > > >> On Oct 21, 2016, at 1:54 PM, Dave Abrahams via swift-dev >> wrote: >> >>

Re: [swift-dev] Purpose of validation-test/Reflection/reflect_*.swift

on Wed Oct 26 2016, Slava Pestov wrote: > The tests are there to ensure the reflection output doesn’t > accidentally break or change. Unless you have reason to think it will break or change *only* for some particular stdlib types, and that reflecting the implementation details of those types i

Re: [swift-dev] Inability to leverage privacy in the stdlib

on Sat Oct 29 2016, Alexis wrote: >> On Oct 29, 2016, at 12:13 AM, Slava Pestov wrote: >> >> It will become the default, but not yet, so yeah, you shouldn’t merge >> anything that only builds > with this flag set. >> >> Can you share the patch that adds private modifiers along with the >> li

Re: [swift-dev] Inability to leverage privacy in the stdlib

port.a(SwiftOnoneSupport.o): >> multiple definition of >> '_TTSfq4n_d___TTSgq5Vs5UInt8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_' >> /usr/bin/ld.gold: >> /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-mast

[swift-dev] libxml/parser.h not found?

Anyone know what this is about? /Users/dave/src/s/swift/utils/build-script --distcc '--lit-args=--distribute -sv' --build-args=-v --skip-build-ios-device --skip-build-tvos-device --skip-build-compiler-rt --swift-stdlib-build-type=Debug --swift-stdlib-enable-assertions=1 --skip-build-benchmarks

Re: [swift-dev] libxml/parser.h not found?

;t know how that could happen, but anyway... a clean reconfigure got me past it, thanks. > Doug > >> On Nov 3, 2016, at 12:54 PM, Dave Abrahams via swift-dev >> wrote: >> >> >> Anyone know what this is about? >> >> /Users/dave/src/s/swift

Re: [swift-dev] Casting shadow protocols

on Fri Nov 04 2016, Slava Pestov wrote: > If the casts are always in one direction, can you make one protocol > refine another? Yeah, I am shocked if they don't do that already. > Also note that @objc protocols are self-conforming as long as they > don’t contain initializers or static methods,

Re: [swift-dev] Casting shadow protocols

on Mon Nov 07 2016, Alexis wrote: >> On Nov 4, 2016, at 11:55 PM, Dave Abrahams via swift-dev >> wrote: >> >> >> on Fri Nov 04 2016, Slava Pestov > <http://swift-dev-at-swift.org/>> wrote: >> >>> If the casts are always in on

Re: [swift-dev] Casting shadow protocols

could ever hope to do?) It might be, if that's the only way it's being used. >> On Nov 7, 2016, at 2:30 PM, Dave Abrahams wrote: >> >> >> on Mon Nov 07 2016, Alexis wrote: >> >>>> On Nov 4, 2016, at 11:55 PM, Dave Abrahams via swift-

[swift-dev] Recent automerges break clang build

https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/416/consoleFull#-1996075066ee1a197b-acac-4b17-83cf-a53b95139a76 shows a build failure I'm reproducing locally. Rolling back to 4caa7532f923e759093df9227df20a36a002d28d (before recent indexing-related changes) fixes it for me. -

Re: [swift-dev] Casting shadow protocols

on Tue Nov 08 2016, Michael Gottesman wrote: >> On Nov 7, 2016, at 11:23 AM, Alexis via swift-dev >> wrote: >> >> >>> On Nov 4, 2016, at 11:55 PM, Dave Abrahams via swift-dev >>> <mailto:swift-dev@swift.org>> wrote: >>> > &g

Re: [swift-dev] Associated type inference fun with RandomAccessCollection

on Mon Nov 07 2016, Robert Widmann wrote: > Voting for 1. This is an ambiguity in stdlib through and through IMO. No, this is the standard library doing the best it can with a type checker that has mostly-unspecified semantics. It can only be considered an ambiguity in the standard library if

Re: [swift-dev] Associated type inference fun with RandomAccessCollection

on Mon Nov 07 2016, Douglas Gregor wrote: > Hi all, > > While working on the type checker, I came across an interesting case for > associated type inference > with the ‘Indices’ type of RandomAccessCollection. At issue is a simple model > of > RandomAccessCollection where the Index type is Int

Re: [swift-dev] Casting shadow protocols

? Do I just get a “no such message” crash at > runtime? > >> >> -Andy >> >>>> On Nov 7, 2016, at 2:30 PM, Dave Abrahams wrote: >>>> >>>> >>>> on Mon Nov 07 2016, Alexis wrote: >>>> >>>>>> On

Re: [swift-dev] Casting shadow protocols

rs with an explicit @objc(selectorname) declaration, to help ensure that we're not picking up the wrong API. > > Do I just get a “no such message” crash at runtime? > >> >> -Andy >> >>>> On Nov 7, 2016, at 2:30 PM, Dave Abrahams wrote: >>>> >>>&g

Re: [swift-dev] Associated type inference fun with RandomAccessCollection

on Tue Nov 08 2016, Douglas Gregor wrote: >> On Nov 8, 2016, at 1:58 PM, Dave Abrahams via swift-dev >> wrote: >> >> >> on Mon Nov 07 2016, Douglas Gregor > <http://swift-dev-at-swift.org/>> > wrote: >> > >>> Hi all, >>&

Re: [swift-dev] [Pitch] Remove "Default will never be executed" Warning?

on Sun Nov 27 2016, Slava Pestov wrote: >> On Nov 27, 2016, at 4:32 PM, David Sweeris via swift-dev >> wrote: >> >>> >>> On Nov 26, 2016, at 5:25 PM, Robert Widmann via swift-dev >>> > wrote: >>> > >>> Hello all, >>> >>> I’ve seen and been a part of a number o

Re: [swift-dev] Namespacing Compiler-Stdlib Interfaces

on Thu Dec 15 2016, Alexis wrote: > Triaging old radars, I came across rdar://27268632 > from Dmitri. The gist of it is that he was proposing grouping up all > the random global functions that are implicitly called by the compiler > under a “namespace” by making them static methods of an enum c

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

on Fri Feb 03 2017, John McCall wrote: >> On Feb 3, 2017, at 7:12 PM, Joe Groff via swift-dev >> wrote: >> Given that most open-coded resilient method lookup paths require an >> extra load dependency to grab the method offset before loading the >> method address itself, we might possibly consi

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

on Mon Feb 06 2017, John McCall wrote: >> On Feb 4, 2017, at 6:45 PM, Dave Abrahams via swift-dev >> wrote: >> on Fri Feb 03 2017, John McCall wrote: >> >>>> On Feb 3, 2017, at 7:12 PM, Joe Groff via swift-dev >>>> wrote: >>>&

Re: [swift-dev] Questions about Swift-CI

on Thu May 11 2017, Pavol Vaskovic wrote: > Hi Mishal, > > Douglas Gregor suggested in SR-4814 (that was merged as dupe into > SR-4669) that I get in contact with you because I’m working on issue > SR-4669 Add a Benchmark_Driver --rerun N option > and I sh

Re: [swift-dev] statically initialized arrays

on Wed Jun 14 2017, Erik Eckstein wrote: > Hi, > > I’m about implementing statically initialized arrays. It’s about > allocating storage for arrays in the data section rather than on the > heap. W00t! I'd like to do the same for String, i.e. encode the entire buffer in the data section. I was

Re: [swift-dev] statically initialized arrays

on Thu Jun 15 2017, Arnold wrote: >> On Jun 14, 2017, at 2:56 PM, Dave Abrahams via swift-dev >> wrote: >> >> >>> on Wed Jun 14 2017, Erik Eckstein wrote: >>> >>> Hi, >>> >>> I’m about implementing statically initial

Re: [swift-dev] statically initialized arrays

on Thu Jun 15 2017, Arnold wrote: >> W00t! I'd like to do the same for String, i.e. encode the entire buffer >> in the data section. I was looking for Array example code to follow but >> couldn't find it. > > We have support for constant string buffers as of PR 8701 and PR > 8692. The former P

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

on Wed Jul 19 2017, Michael Ilseman wrote: > CC Dave/Max. Is there any current value to this library? There's plenty of value in there, but none that justifies keeping it in the standard library. Someone should spin off the contents to one or more SwiftPM projects. > Is there anything in the

Re: [swift-dev] What to do with the rest of SE-0174?

on Thu Jul 20 2017, Gmail wrote: > Hi. > > I was looking to implement SE-0174 > > (Change filter to return an associated type) but noticed that a different > RangeReplaceableCollection.filter implem

Re: [swift-dev] [Proposal] RangeReplaceableCollection should inherits from MutableCollection

Sent from my iPhone > On Dec 5, 2017, at 12:19 AM, Cao, Jiannan via swift-dev > wrote: > > > But, I mean, what subscript (restrict to the length) could do is subset of p > replaceSubrange could do, right? True but that would imply the opposite of the refinement relationship you’re suggest

Re: [swift-dev] Conditional conformance: Removing the opt-in flag

> On Dec 18, 2017, at 4:52 PM, Douglas Gregor via swift-dev > wrote: > > Hi all, > > A little while back, I added an error to the Swift 4.1 compiler that > complains if one tries to use conditional conformances, along with a flag > “-enable-experimental-conditional-conformances” to enable t