Re: [swift-users] [swift-evolution] How does "Sequence.joined" work?

[Rob Mayoff via swift-users]

On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users <
swift-users@swift.org> wrote:

>
>
> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <
> swift-evolut...@swift.org> wrote:
>
>> Yes, exactly. An Array is a struct wrapper for a reference type
>> representing storage. Mutating functions first check if they own the only
>> reference to the storage using isKnownUniquelyReferenced
>> .
>> If not, they make a fresh copy before applying the mutating operation.
>>
>> There's no difference for `let` arrays. Access control is enforced at
>> compile-time through Array's design: the compiler will prevent you from
>> calling `mutating` functions on `let` structs, and Array is careful to not
>> expose functionality that could modify its storage outside of `mutating`
>> functions.
>>
>> There is no secret. Anyone could implement the same thing only using
>> publicly available and documented compiler features. In fact, it's been
>> done already for some very powerful collections
>> .
>>
>
> This isn’t entirely true. That BTree module readme seems to contain a lot
> of unsubstantiated hyperbole. It’s possible to implement a classic
> red-black tree in Swift that performs better than a sorted Array, down to
> about *n* = 1,500 items, not *n* = *100,000* items as it claims.
> (Actually, heap allocators these days are good enough that performance is
> on par with Array all the way down to *n* = 1.) Red-Black trees are slow
> when *distributed* as packages because of the crossmodule optimization
> boundary. (This also means the BTree module is much slower than Array for
> most reasonable *n*.) It’s possible to write modules using compiler
> attributes that mitigate this slowdown (reclaiming over 50% of lost
> performance) but it’s hacky and forces you to design your libraries like
> the standard library (meaning: ugly underscored properties everywhere and
> everything is public). And these features aren’t “publicly available” or
> documented at all.
>

This seems harsh. I didn't notice Félix making any claims about BTree's
performance. The necessary API for implementing COW is indisputably public
and documented:

https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-evolution] for-else syntax

[Rob Mayoff via swift-users]

On Fri, Feb 3, 2017 at 7:15 PM, Howard Lovatt via swift-users <
swift-users@swift.org> wrote:

> Why not add to the library:
>
> extension Sequence {
> func forEach(_ eacher: (Iterator.Element) throws -> Void, elser: ()
> throws -> Void) rethrows {
>

This doesn't work with break or continue and changes the meaning of return.

It would be nice for Swift to support Tcl-like exceptional return codes so
we can build control flow functions that work with break, continue, and
return properly.

http://www.tcl.tk/man/tcl/TclCmd/return.htm
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Need better name, want to hide generator

[Rob Mayoff via swift-users]

>
> 1. Can anyone recommended a better name than Cartesian? 2D doesn't work
> for the compiler and I'm looking for something that doesn't seem
> "floating-point"-y
>

"AllPairs" seems self-explanatory.

"CrossJoin" should be intuitive to anyone familiar with relational
databases.

"product" sounds like it might be multiplying elements with each other.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users