[swift-dev] Should non-final classes be allowed to conform to Collection?

Hi all, Consider this code, class Base : Collection { var startIndex: Int { return 0 } var endIndex: Int { return 10 } func index(after i: Int) -> Int { return i + 1 } subscript(index: Int) -> Int { return index } } We infer the associated type ‘Iterator’ as ‘IndexingIterator’. I can

Re: [swift-dev] Should non-final classes be allowed to conform to Collection?

Another solution is to change the Collection protocol as follows, protocol Collection { associatedtype ConformingType = Self associatedtype Iterator = IndexingIterator … } extension Collection where Iterator == IndexingIterator { func makeIterator() -> IndexingIterator { … } } I believe

Re: [swift-dev] Should non-final classes be allowed to conform to Collection?

I just tried this and it causes major breakage with associated type inference and the expression checker so its probably more trouble than its worth. So back to the three options: 1) Do nothing, and give up on fixing https://bugs.swift.org/browse/SR-617 fo

Re: [swift-dev] Should non-final classes be allowed to conform to Collection?

Actually I think I figured out a solution. If the witness has ‘Self’ in a non-covariant position, we use the concrete type for Self. Otherwise, we do it the new way. This makes both examples in https://gist.github.com/slavapestov/f455c6184b402f3ffc656f904f1e5d59

[swift-dev] Failure: Swift master branch build failing on x86 (Ubuntu 16.04).

Hi, Swift "master" branch is failing to build on x86 running Ubuntu 16,04 with following error. make[2]: Entering directory '/root/swift/build/Unix_Makefiles-ReleaseAssert/swift-linux-x86_64' make[2]: *** No rule to make target 'stdlib/public/runtime/CMakeFiles/section_magic_loader-linux-x86_64.d

Re: [swift-dev] Failure: Swift master branch build failing on x86 (Ubuntu 16.04).

> On 6 Oct 2017, at 12:42, Atul Sowani via swift-dev > wrote: > > Hi, > > Swift "master" branch is failing to build on x86 running Ubuntu 16,04 with > following error. Most of the recent builds appear to be working: https://ci.swift.org/view/swift-master-next/job/oss-swift-incremental-RA-l

Re: [swift-dev] Failure: Swift master branch build failing on x86 (Ubuntu 16.04).

Thanks Alex! I used the clean/reset command and then tried rebuilding it, but got the very same error. I am using master branch, latest (top-of-the-tree) version: git clone https://github.com/apple/swift.git ./swift/utils/update-checkout --clone cd swift utils/build-script -c -m -R --verbose-build

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

+Saleem, who's been looking at Dispatch's build system. > On Oct 5, 2017, at 22:12, Slava Pestov wrote: > > We keep seeing this failure in the bots: > > src/libdispatch.so: error: undefined reference to > ‘_T0s17_assertionFailures5NeverOs12StaticStringV_SSAE4fileSu4lines6UInt32V5flagstFTfq4nx

[swift-dev] Debugger (lldb or gdb) does not show variable value in swift code

Hi, I build swift compiler (v4.0) with debug mode ("-d"), however when debugging compiler swift code, it can not show the variable value. Here is an example: frame #0: 0x7761d50c libswiftCore.so`_allocateUninitializedArray(builtinCount=1) at Arrays.swift:3347

[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

[swift-dev] I need t change my mail address

hell, I need to move my emial address where I receive this mailing to icloud account, where to perform the task? ing. Conti G. Enrico ingco...@ingconti.com Ordine Ingegneri di Monza al n. A894 via Duca degli Abruzzi, 29 20090 MONZA MI ITALY 0039-039-324723 www.i

Re: [swift-dev] Reducing array abstraction

> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev > wrote: > > 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 varar