Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Xiaodi Wu via swift-evolution]

On Thu, Aug 3, 2017 at 11:03 PM, Gwendal Roué via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Le 3 août 2017 à 19:10, Itai Ferber  a écrit :
> >
> > I just mentioned this in my other email, but to point out here: the
> reason this works in your case is because you adopt these methods as static
> funcs and can reasonably rely on subclasses of NSData, NSNumber, NSString,
> etc. to do the right thing because of work done behind the scenes in the
> ObjC implementations of these classes (and because we’ve got established
> subclassing requirements on these methods — all subclasses of these classes
> are going to look approximately the same without doing anything crazy).
> >
> > This would not work for Codable in the general case, however, where
> subclasses likely need to add additional storage, properties, encoded
> representations, etc., without equivalent requirements, either via
> additional protocols or conventions.
>
> Thaks for your explanation why a static method in a protocol is able to
> instantiate non final classes like NSData, NSDate, NSNumber,
> NSDecimalNumber, NSString, etc.
>
> Is this "privilege" stable? Can I rely on it to be maintained over time?
> Or would it be a better idea to drop support for those low-level Foundation
> classes, because they'll eventually become regular classes without any
> specific support? This would not harm that much: Data, Date, String are
> there for a reason. NSDecimalNumber is the only one of its kind, though.
>

Why not Decimal?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Félix Cloutier via swift-evolution]

> Le 3 août 2017 à 17:44, Taylor Swift via swift-evolution 
>  a écrit :
> 
> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution 
> > wrote:
>>> 
>>> The root cause, of course, is that the VLAs require new stack allocations 
>>> each time, and the stack is only deallocated as one lump when the frame 
>>> ends.
>> 
>> That is true of alloca(), but not of VLAs.  VLAs are freed when they go out 
>> of scope.
>> 
> 
> Learned something today.
> 
> Anyway, if the goal is stack allocation, I would prefer that we explored 
> other ways to achieve it before jumping to a new array-type. I’m not really a 
> fan of a future where [3; Double] is one type and (Double, Double, Double) is 
> something else, and Array is yet another thing.
> 
> They are completely different things. 
> 
> [3; Double] is three contiguous Doubles which may or may not live on the 
> stack. 
> 
> (Double, Double, Double) is three Doubles bound to a single variable name, 
> which the compiler can rearrange for optimal performance and may or may not 
> live on the stack. 

To be clear, there is no Swift value type that guarantees that the order in 
which fields are laid out is the same as the order in which they're declared. 
It's not just tuples. (Structs imported from C are always laid out with their C 
layout, of course.)

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Taylor Swift via swift-evolution]

For what it’s worth, I’d be happy with just subscripts on tuples and some
form of shorthand for their size. Maybe

(Float ... 5)

or something like that. That would obviate the need for an attribute too.

On Thu, Aug 3, 2017 at 11:48 PM, Karl Wagner  wrote:

>
> Actually, if you do a lot of graphics programming like I do, the memory
> layout is very, *very* important. Swift may not care about layout, but
> many APIs that it interacts with do.
>
>
> Sure; I’m well-aware of how important it can be to decide on an
> appropriate memory layout. I’m very much in favour of opting-in to
> contiguous layout for tuples.
>
> Is @fixed_layout actually planned to be part of the language? I was under
> the impression it’s just a placeholder attribute. Either way, I’d
> appreciate not having to write Float sixteen times for a 4x4 matrix type.
>
>
> AFAIK @fixed_layout is a placeholder attribute. And I’m also very much in
> favour of a shorthand for declaring a fixed-size list.
>
> I just don’t see why we need to introduce this new kind of list-like thing
> in order to get what we need. It makes it harder to project a coherent
> message about when to use which data-type.
>
> - Karl
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Gwendal Roué via swift-evolution]

> Le 3 août 2017 à 19:10, Itai Ferber  a écrit :
> 
> I just mentioned this in my other email, but to point out here: the reason 
> this works in your case is because you adopt these methods as static funcs 
> and can reasonably rely on subclasses of NSData, NSNumber, NSString, etc. to 
> do the right thing because of work done behind the scenes in the ObjC 
> implementations of these classes (and because we’ve got established 
> subclassing requirements on these methods — all subclasses of these classes 
> are going to look approximately the same without doing anything crazy).
> 
> This would not work for Codable in the general case, however, where 
> subclasses likely need to add additional storage, properties, encoded 
> representations, etc., without equivalent requirements, either via additional 
> protocols or conventions.

Thaks for your explanation why a static method in a protocol is able to 
instantiate non final classes like NSData, NSDate, NSNumber, NSDecimalNumber, 
NSString, etc.

Is this "privilege" stable? Can I rely on it to be maintained over time? Or 
would it be a better idea to drop support for those low-level Foundation 
classes, because they'll eventually become regular classes without any specific 
support? This would not harm that much: Data, Date, String are there for a 
reason. NSDecimalNumber is the only one of its kind, though.

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Karl Wagner via swift-evolution]

> Actually, if you do a lot of graphics programming like I do, the memory 
> layout is very, very important. Swift may not care about layout, but many 
> APIs that it interacts with do. 
> 

Sure; I’m well-aware of how important it can be to decide on an appropriate 
memory layout. I’m very much in favour of opting-in to contiguous layout for 
tuples.

> Is @fixed_layout actually planned to be part of the language? I was under the 
> impression it’s just a placeholder attribute. Either way, I’d appreciate not 
> having to write Float sixteen times for a 4x4 matrix type.
> 

AFAIK @fixed_layout is a placeholder attribute. And I’m also very much in 
favour of a shorthand for declaring a fixed-size list.

I just don’t see why we need to introduce this new kind of list-like thing in 
order to get what we need. It makes it harder to project a coherent message 
about when to use which data-type.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Taylor Swift via swift-evolution]

On Thu, Aug 3, 2017 at 11:17 PM, Karl Wagner  wrote:

>
> On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> The root cause, of course, is that the VLAs require new stack allocations
>> each time, and the stack is only deallocated as one lump when the frame
>> ends.
>>
>>
>> That is true of alloca(), but not of VLAs.  VLAs are freed when they go
>> out of scope.
>>
>>
>> Learned something today.
>>
>> Anyway, if the goal is stack allocation, I would prefer that we explored
>> other ways to achieve it before jumping to a new array-type. I’m not really
>> a fan of a future where [3; Double] is one type and (Double, Double,
>> Double) is something else, and Array is yet another thing.
>>
>
> They are completely different things.
>
> [3; Double] is three *contiguous* Doubles which may or may not live on
> the stack.
>
> (Double, Double, Double) is three Doubles bound to a single variable
> *name*, which the compiler can rearrange for optimal performance and may
> or may not live on the stack.
>
> Array is an vector of Doubles that can dynamically grow and always
> lives in the heap.
>
>
>
> Yeah, I understand that — the problem I have is that I’m not sure it’s
> going to be obvious to everybody *else* when they should use which. We
> need to balance semantic purity against simplicity and ease-of-learning.
>
> For example, I’m not sure many users are aware that tuple elements in
> Swift don’t have an ordered relationship; they certainly give that
> impression. This is especially confusing as "In mathematics a tuple is a
> finite ordered list (sequence) of elements.” [https://en.wikipedia.org/
> wiki/Tuple]
>
>
>> From what I’ve read so far, the problem with stack-allocating some Array
>> that you can pass to another function and which otherwise does not escape,
>> is that the function may make an escaping reference (e.g. assigning it to
>> an ivar or global, or capturing it in a closure).
>>
>> How about if the compiler treated every Array it receives in a function
>> as being potentially stack-allocated. The first time you capture it, it
>> will check and copy to the heap if necessary. All subsequent escapes
>> (including passing to other functions) use the Array known to be allocated
>> on the heap, avoiding further checking or copying within the function.
>>
>> The same goes for Dictionary, and really any arbitrary value-type with
>> COW storage. The memory that those types allocate is part of the value, so
>> it would be cool if we could treat it like that.
>>
>>
> This is not true. FSAs have nothing to do with automatic storage, their
> static size only makes them *eligible* to live on the stack, as tuples
> are now. The defining quality of FSAs is that they are static and
> contiguous.
>
>
> Really, the only *practical* difference between a FSA and a tuple is the
> memory layout. Do most users really need to care about that? For those
> users that do, wouldn’t an @-attribute be a less intrusive change to the
> language than a whole new list-style type?
>
> For example, the benefit to having Collection-conforming tuples as our
> FSAs would be that they don’t necessarily have to be contiguous. If you
> have a large multi-dimensional list of Bools or some other tiny type, you
> might also *benefit* from those layout optimisations.
>
> I like the simplicity in telling people:
>
> - If you need a dynamically-sized list, use an Array
> - If you need a fixed-sized list, use a tuple (and it will get an
> optimised layout. You can override this with an attribute, similar to
> @fixed_layout or @inlineable).
>
> - Karl
>

Actually, if you do a lot of graphics programming like I do, the memory
layout is very, *very* important. Swift may not care about layout, but many
APIs that it interacts with do.

Is @fixed_layout actually planned to be part of the language? I was under
the impression it’s just a placeholder attribute. Either way, I’d
appreciate not having to write Float sixteen times for a 4x4 matrix type.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Karl Wagner via swift-evolution]

> On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution 
>  wrote:
> 
> 
> 
> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution 
> > wrote:
>>> 
>>> The root cause, of course, is that the VLAs require new stack allocations 
>>> each time, and the stack is only deallocated as one lump when the frame 
>>> ends.
>> 
>> That is true of alloca(), but not of VLAs.  VLAs are freed when they go out 
>> of scope.
>> 
> 
> Learned something today.
> 
> Anyway, if the goal is stack allocation, I would prefer that we explored 
> other ways to achieve it before jumping to a new array-type. I’m not really a 
> fan of a future where [3; Double] is one type and (Double, Double, Double) is 
> something else, and Array is yet another thing.
> 
> They are completely different things. 
> 
> [3; Double] is three contiguous Doubles which may or may not live on the 
> stack. 
> 
> (Double, Double, Double) is three Doubles bound to a single variable name, 
> which the compiler can rearrange for optimal performance and may or may not 
> live on the stack. 
> 
> Array is an vector of Doubles that can dynamically grow and always 
> lives in the heap.
>  

Yeah, I understand that — the problem I have is that I’m not sure it’s going to 
be obvious to everybody else when they should use which. We need to balance 
semantic purity against simplicity and ease-of-learning.

For example, I’m not sure many users are aware that tuple elements in Swift 
don’t have an ordered relationship; they certainly give that impression. This 
is especially confusing as "In mathematics a tuple is a finite ordered list 
(sequence) of elements.” [https://en.wikipedia.org/wiki/Tuple 
]

> 
> From what I’ve read so far, the problem with stack-allocating some Array that 
> you can pass to another function and which otherwise does not escape, is that 
> the function may make an escaping reference (e.g. assigning it to an ivar or 
> global, or capturing it in a closure).
> 
> How about if the compiler treated every Array it receives in a function as 
> being potentially stack-allocated. The first time you capture it, it will 
> check and copy to the heap if necessary. All subsequent escapes (including 
> passing to other functions) use the Array known to be allocated on the heap, 
> avoiding further checking or copying within the function.
> 
> The same goes for Dictionary, and really any arbitrary value-type with COW 
> storage. The memory that those types allocate is part of the value, so it 
> would be cool if we could treat it like that.
> 
> 
> This is not true. FSAs have nothing to do with automatic storage, their 
> static size only makes them eligible to live on the stack, as tuples are now. 
> The defining quality of FSAs is that they are static and contiguous. 

Really, the only practical difference between a FSA and a tuple is the memory 
layout. Do most users really need to care about that? For those users that do, 
wouldn’t an @-attribute be a less intrusive change to the language than a whole 
new list-style type?

For example, the benefit to having Collection-conforming tuples as our FSAs 
would be that they don’t necessarily have to be contiguous. If you have a large 
multi-dimensional list of Bools or some other tiny type, you might also benefit 
from those layout optimisations.

I like the simplicity in telling people:

- If you need a dynamically-sized list, use an Array
- If you need a fixed-sized list, use a tuple (and it will get an optimised 
layout. You can override this with an attribute, similar to @fixed_layout or 
@inlineable).

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Robert Bennett via swift-evolution]

Where do constant Arrays currently live? I hope the answer is on the stack, 
since their size doesn’t change.

> On Aug 3, 2017, at 8:44 PM, Taylor Swift via swift-evolution 
>  wrote:
> 
> 
> 
> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution 
>  wrote:
 
 The root cause, of course, is that the VLAs require new stack allocations 
 each time, and the stack is only deallocated as one lump when the frame 
 ends.
>>> 
>>> That is true of alloca(), but not of VLAs.  VLAs are freed when they go out 
>>> of scope.
>>> 
>> 
>> Learned something today.
>> 
>> Anyway, if the goal is stack allocation, I would prefer that we explored 
>> other ways to achieve it before jumping to a new array-type. I’m not really 
>> a fan of a future where [3; Double] is one type and (Double, Double, Double) 
>> is something else, and Array is yet another thing.
> 
> They are completely different things. 
> 
> [3; Double] is three contiguous Doubles which may or may not live on the 
> stack. 
> 
> (Double, Double, Double) is three Doubles bound to a single variable name, 
> which the compiler can rearrange for optimal performance and may or may not 
> live on the stack. 
> 
> Array is an vector of Doubles that can dynamically grow and always 
> lives in the heap.
>  
>> 
>> From what I’ve read so far, the problem with stack-allocating some Array 
>> that you can pass to another function and which otherwise does not escape, 
>> is that the function may make an escaping reference (e.g. assigning it to an 
>> ivar or global, or capturing it in a closure).
>> 
>> How about if the compiler treated every Array it receives in a function as 
>> being potentially stack-allocated. The first time you capture it, it will 
>> check and copy to the heap if necessary. All subsequent escapes (including 
>> passing to other functions) use the Array known to be allocated on the heap, 
>> avoiding further checking or copying within the function.
>> 
>> The same goes for Dictionary, and really any arbitrary value-type with COW 
>> storage. The memory that those types allocate is part of the value, so it 
>> would be cool if we could treat it like that.
>> 
> 
> This is not true. FSAs have nothing to do with automatic storage, their 
> static size only makes them eligible to live on the stack, as tuples are now. 
> The defining quality of FSAs is that they are static and contiguous. 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Karl Wagner via swift-evolution]

>> 
>> The root cause, of course, is that the VLAs require new stack allocations 
>> each time, and the stack is only deallocated as one lump when the frame ends.
> 
> That is true of alloca(), but not of VLAs.  VLAs are freed when they go out 
> of scope.
> 

Learned something today.

Anyway, if the goal is stack allocation, I would prefer that we explored other 
ways to achieve it before jumping to a new array-type. I’m not really a fan of 
a future where [3; Double] is one type and (Double, Double, Double) is 
something else, and Array is yet another thing.

>From what I’ve read so far, the problem with stack-allocating some Array that 
>you can pass to another function and which otherwise does not escape, is that 
>the function may make an escaping reference (e.g. assigning it to an ivar or 
>global, or capturing it in a closure).

How about if the compiler treated every Array it receives in a function as 
being potentially stack-allocated. The first time you capture it, it will check 
and copy to the heap if necessary. All subsequent escapes (including passing to 
other functions) use the Array known to be allocated on the heap, avoiding 
further checking or copying within the function.

The same goes for Dictionary, and really any arbitrary value-type with COW 
storage. The memory that those types allocate is part of the value, so it would 
be cool if we could treat it like that.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

A math library should include vectorized operations as part of its vector
type support; i currently use this snippet
 to
cover that. Even though they are evaluated as scalars right now, if
simd/sse support ever comes to Linux it’ll be easy to switch to it since
all the vectorizable operations are already routed through the “vector”
functions.


On Thu, Aug 3, 2017 at 5:03 PM, Nicolas Fezans 
wrote:

> Interesting figures. I will not try to discuss the generics, inlineable,
> etc. there are certainly good observations and comments to make here, but
> most people in this list know certainly more about it than I do.
>
> I just want to point out that IMO a core math library for swift should
> comply with the IEEE 754 standard in terms of precision, domain, and
> special values. *On the long term*, it should ideally be able to use SIMD
> instructions when applied to arrays/matrices or when the compiler can
> autovectorize some loops.
>
> On Thu, Aug 3, 2017 at 8:52 PM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> In an effort to get this thread back on track, I tried implementing
>> cos(_:) in pure generic Swift code, with the BinaryFloatingPoint protocol.
>> It deviates from the _cos(_:) intrinsic by no more than
>> 5.26362703423544e-11. Adding more terms to the approximation only has a
>> small penalty to the performance for some reason.
>>
>> To make the benchmarks fair, and explore the idea of distributing a Math
>> module without killing people on the cross-module optimization boundary, I
>> enabled some of the unsafe compiler attributes. All of these benchmarks are
>> cross-module calls, as if the math module were downloaded as a dependency
>> in the SPM.
>>
>> == Relative execution time (lower is better) ==
>>
>> llvm intrinsic   :  3.133
>> glibc cos()  :  3.124
>>
>> no attributes: 43.675
>> with specialization  :  4.162
>> with inlining:  3.108
>> with inlining and specialization :  3.264
>>
>> As you can see, the pure Swift generic implementation actually beats the
>> compiler intrinsic (and the glibc cos() but I guess they’re the same thing)
>> when inlining is used, but for some reason generic specialization and
>> inlining don’t get along very well.
>>
>> Here’s the source implementation. It uses a taylor series (!) which
>> probably isn’t optimal but it does prove that cos() and sin() can be
>> implemented as generics in pure Swift, be distributed as a module outside
>> the stdlib, and still achieve competitive performance with the llvm
>> intrinsics.
>>
>> @_inlineable
>> //@_specialize(where F == Float)
>> //@_specialize(where F == Double)
>> public
>> func cos(_ x:F) -> F where F:BinaryFloatingPoint
>> {
>> let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
>> quadrant:Int = Int(x * (2 / F.pi))
>>
>> switch quadrant
>> {
>> case 0:
>> return  cos(on_first_quadrant:x)
>> case 1:
>> return -cos(on_first_quadrant: F.pi - x)
>> case 2:
>> return -cos(on_first_quadrant: x - F.pi)
>> case 3:
>> return -cos(on_first_quadrant: 2 * F.pi - x)
>> default:
>> fatalError("unreachable")
>> }
>> }
>>
>> @_versioned
>> @_inlineable
>> //@_specialize(where F == Float)
>> //@_specialize(where F == Double)
>> func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
>> {
>> let x2:F = x * x
>> var y:F  = -0.00114707451267755432394
>> for c:F in [0.2087675698165412591559,
>>-0.00275573192239332256421489,
>> 0.2480158730158702330045157,
>>-0.00138880310186415,
>> 0.0415319411988,
>>-0.41637437,
>> 0.99914771
>> ]
>> {
>> y = x2 * y + c
>> }
>> return y
>> }
>>
>> On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> It’s important to remember that computers are mathematical machines, and
>>> some functions which are implemented in hardware on essentially every
>>> platform (like sin/cos/etc) are definitely best implemented as compiler
>>> intrinsics.
>>>
>>>
>>> sin/cos/etc are implemented in software, not hardware. x86 does have the
>>> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
>>> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
>>> and too inaccurate for serious use today. There are no analogous
>>> instructions on ARM or PPC.
>>>
>>> – Steve
>>>
>>> ___
>>> swift-evolution mailing list
>>> 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Thu, Aug 3, 2017 at 7:12 PM, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> It’s important to remember that computers are mathematical machines, and
> some functions which are implemented in hardware on essentially every
> platform (like sin/cos/etc) are definitely best implemented as compiler
> intrinsics.
>
>
> sin/cos/etc are implemented in software, not hardware. x86 does have the
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
> and too inaccurate for serious use today. There are no analogous
> instructions on ARM or PPC.
>
> – Steve
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> Hah that’s pretty cool; I think I learned in EE years ago that it was
> implemented with a lookup table inside the CPU and never bothered to
> question it.
>
> The pure-Swift cosine implementation looks cool.
>

I’m pretty sure it can be improved greatly, at least for Double.
Unfortunately performance falls off a cliff for Float for some reason, i
don’t know why.

>
> As for the larger discussion about a Swift maths library: in general, it’s
> hard for any new Swift-only package to get off the ground without a more
> comprehensive package manager. The current version doesn’t support most of
> the Swift projects being worked on every day. Swift is also still a
> relatively young language - the new integer protocols have never even
> shipped in a stable release. Considering where we are, it’s not really
> surprising that most of the Swift maths libraries are still a bit
> rudimentary; I expect they will naturally evolve and develop in time, the
> way open-source code does.
>
>
Most of the SPM’s limitations have workarounds, the problem is it’s just
not very convenient, i.e. local and non-git dependencies. Other features
like gyb, I’m not sure if it’s a good idea to bring to the SPM. gyb is a
band-aid over deeper limitations of the language.


> It’s also worth considering that our excellent bridging with C removes
> some of the impetus to rewrite all your battle-tested maths code in Swift.
> The benefits are not obvious; the stage is set for pioneers to experiment
> and show the world why they should be writing their maths code in Swift.
>
>
The glibc/llvm functions are not generic. You cannot use _cos(_:) on a
protocol type like BinaryFloatingPoint. A pure Swift implementation would
allow generic programming with trig and other math functions; right now
anything beyond sqrt() requires manual specialization.


> - Karl
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Thu, Aug 3, 2017 at 7:17 PM, Karl Wagner  wrote:

>
> On 3. Aug 2017, at 20:52, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In an effort to get this thread back on track, I tried implementing
> cos(_:) in pure generic Swift code, with the BinaryFloatingPoint protocol.
> It deviates from the _cos(_:) intrinsic by no more than
> 5.26362703423544e-11. Adding more terms to the approximation only has a
> small penalty to the performance for some reason.
>
> To make the benchmarks fair, and explore the idea of distributing a Math
> module without killing people on the cross-module optimization boundary, I
> enabled some of the unsafe compiler attributes. All of these benchmarks are
> cross-module calls, as if the math module were downloaded as a dependency
> in the SPM.
>
> == Relative execution time (lower is better) ==
>
> llvm intrinsic   :  3.133
> glibc cos()  :  3.124
>
> no attributes: 43.675
> with specialization  :  4.162
> with inlining:  3.108
> with inlining and specialization :  3.264
>
> As you can see, the pure Swift generic implementation actually beats the
> compiler intrinsic (and the glibc cos() but I guess they’re the same thing)
> when inlining is used, but for some reason generic specialization and
> inlining don’t get along very well.
>
> Here’s the source implementation. It uses a taylor series (!) which
> probably isn’t optimal but it does prove that cos() and sin() can be
> implemented as generics in pure Swift, be distributed as a module outside
> the stdlib, and still achieve competitive performance with the llvm
> intrinsics.
>
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> public
> func cos(_ x:F) -> F where F:BinaryFloatingPoint
> {
> let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
> quadrant:Int = Int(x * (2 / F.pi))
>
> switch quadrant
> {
> case 0:
> return  cos(on_first_quadrant:x)
> case 1:
> return -cos(on_first_quadrant: F.pi - x)
> case 2:
> return -cos(on_first_quadrant: x - F.pi)
> case 3:
> return -cos(on_first_quadrant: 2 * F.pi - x)
> default:
> fatalError("unreachable")
> }
> }
>
> @_versioned
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
> {
> let x2:F = x * x
> var y:F  = -0.00114707451267755432394
> for c:F in [0.2087675698165412591559,
>-0.00275573192239332256421489,
> 0.2480158730158702330045157,
>-0.00138880310186415,
> 0.0415319411988,
>-0.41637437,
> 0.99914771
> ]
> {
> y = x2 * y + c
> }
> return y
> }
>
> On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> It’s important to remember that computers are mathematical machines, and
>> some functions which are implemented in hardware on essentially every
>> platform (like sin/cos/etc) are definitely best implemented as compiler
>> intrinsics.
>>
>>
>> sin/cos/etc are implemented in software, not hardware. x86 does have the
>> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
>> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
>> and too inaccurate for serious use today. There are no analogous
>> instructions on ARM or PPC.
>>
>> – Steve
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> Just a guess, but I’d expect inlining implies specialisation. It would be
> weird if the compiler inlined a chunk of unoptimised generic code in to
> your function.
>
> Pretty cool figures, though.
>
> - Karl
>
>
The weird part is that generic specialization actually *hurt* performance.
I understand why inlining can be harmful sometimes, but I always assumed
specialization was always helpful. Weird. Can a core team member weigh in
here?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Karl Wagner via swift-evolution]

> On 3. Aug 2017, at 20:52, Taylor Swift via swift-evolution 
>  wrote:
> 
> In an effort to get this thread back on track, I tried implementing cos(_:) 
> in pure generic Swift code, with the BinaryFloatingPoint protocol. It 
> deviates from the _cos(_:) intrinsic by no more than 5.26362703423544e-11. 
> Adding more terms to the approximation only has a small penalty to the 
> performance for some reason.
> 
> To make the benchmarks fair, and explore the idea of distributing a Math 
> module without killing people on the cross-module optimization boundary, I 
> enabled some of the unsafe compiler attributes. All of these benchmarks are 
> cross-module calls, as if the math module were downloaded as a dependency in 
> the SPM.
> 
> == Relative execution time (lower is better) ==
> 
> llvm intrinsic   :  3.133
> glibc cos()  :  3.124
> 
> no attributes: 43.675
> with specialization  :  4.162
> with inlining:  3.108
> with inlining and specialization :  3.264
> 
> As you can see, the pure Swift generic implementation actually beats the 
> compiler intrinsic (and the glibc cos() but I guess they’re the same thing) 
> when inlining is used, but for some reason generic specialization and 
> inlining don’t get along very well.
> 
> Here’s the source implementation. It uses a taylor series (!) which probably 
> isn’t optimal but it does prove that cos() and sin() can be implemented as 
> generics in pure Swift, be distributed as a module outside the stdlib, and 
> still achieve competitive performance with the llvm intrinsics.
> 
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> public
> func cos(_ x:F) -> F where F:BinaryFloatingPoint
> {
> let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
> quadrant:Int = Int(x * (2 / F.pi))
> 
> switch quadrant
> {
> case 0:
> return  cos(on_first_quadrant:x)
> case 1:
> return -cos(on_first_quadrant: F.pi - x)
> case 2:
> return -cos(on_first_quadrant: x - F.pi)
> case 3:
> return -cos(on_first_quadrant: 2 * F.pi - x)
> default:
> fatalError("unreachable")
> }
> }
> 
> @_versioned
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
> {
> let x2:F = x * x
> var y:F  = -0.00114707451267755432394
> for c:F in [0.2087675698165412591559,
>-0.00275573192239332256421489,
> 0.2480158730158702330045157,
>-0.00138880310186415,
> 0.0415319411988,
>-0.41637437,
> 0.99914771
> ]
> {
> y = x2 * y + c
> }
> return y
> }
> 
> On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution 
> > wrote:
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> It’s important to remember that computers are mathematical machines, and 
>> some functions which are implemented in hardware on essentially every 
>> platform (like sin/cos/etc) are definitely best implemented as compiler 
>> intrinsics.
> 
> sin/cos/etc are implemented in software, not hardware. x86 does have the 
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement 
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow 
> and too inaccurate for serious use today. There are no analogous instructions 
> on ARM or PPC.
> 
> – Steve
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Just a guess, but I’d expect inlining implies specialisation. It would be weird 
if the compiler inlined a chunk of unoptimised generic code in to your function.

Pretty cool figures, though.

- Karl

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Karl Wagner via swift-evolution]

> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution 
>  wrote:
> 
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> It’s important to remember that computers are mathematical machines, and 
>> some functions which are implemented in hardware on essentially every 
>> platform (like sin/cos/etc) are definitely best implemented as compiler 
>> intrinsics.
> 
> sin/cos/etc are implemented in software, not hardware. x86 does have the 
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement 
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow 
> and too inaccurate for serious use today. There are no analogous instructions 
> on ARM or PPC.
> 
> – Steve
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Hah that’s pretty cool; I think I learned in EE years ago that it was 
implemented with a lookup table inside the CPU and never bothered to question 
it.

The pure-Swift cosine implementation looks cool.

As for the larger discussion about a Swift maths library: in general, it’s hard 
for any new Swift-only package to get off the ground without a more 
comprehensive package manager. The current version doesn’t support most of the 
Swift projects being worked on every day. Swift is also still a relatively 
young language - the new integer protocols have never even shipped in a stable 
release. Considering where we are, it’s not really surprising that most of the 
Swift maths libraries are still a bit rudimentary; I expect they will naturally 
evolve and develop in time, the way open-source code does.

It’s also worth considering that our excellent bridging with C removes some of 
the impetus to rewrite all your battle-tested maths code in Swift. The benefits 
are not obvious; the stage is set for pioneers to experiment and show the world 
why they should be writing their maths code in Swift.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

[Erica Sadun via swift-evolution]

When moving to a forum, the problem becomes a thread splintering to an 
overwhelming tree. I'd prefer to see a single primary thread (as in the mailing 
lists) with breakout threads for working groups. These could be built either 
around already identified areas (see manifestos) or future directions (such as 
mathematics, fp, merging features from other languages). 
I think announce should announce.  One thread, one purpose.
I think evolution should have a review forum: one thread for each proposal.
Pitches and RFC should have their own forum, with individual threads. The 
dangers here are (1) losing good ideas, (2) good ideas that are timed poorly, 
(3) redundant ideas from not having found previous discussions, (4) well 
intentioned but inappropriate ideas. Having a way to filter types 3 and 4 out 
to a subforum to raise the S:N should be possible but will require some kind of 
moderation (such as Xiodi Wu has put such effort into supporting)
Working groups need their own development area. There needs to be some sort of 
top-level organization to make this usable ("Generics", "Dispatch", 
"Calendar/Clocks/Time", "Mathematics", "Strings", "Collections", whatever), but 
there should also be a level of flexiblity. I'd recommend giving manifesto 
topics initial priority at the top level but I'd also suggest that there have 
to be some kind of effort to open a new discussion area, to limit the number of 
"ghost forums".
A SE version of a FAQ, be it "Commonly Proposed"/"Commonly Rejected" and some 
kind of Quinn-like Eskimo support for directing and moderating.

The measures of success are:

* Can track news ("announce")
* Can participate in active reviews
* Can read archived reviews
* Can pitch and develop proposals as part of a working group
* Can search for previous discussions
* Can look up whether common topics have already been hit 
* Can support a small and well-populated forum hierarchy with few orphans and 
ghosts
* Communicates that the forum is a non-social working area and a public record 
of language development.

-- E


> On Aug 1, 2017, at 11:13 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> A while back a decision was reached to move from using mailing lists for 
> swift-evolution to using a forum, specifically Discourse.  At the time that 
> decision was made, efforts had been already well committed for supporting the 
> development of Swift 4 — including efforts supporting important 
> infrastructure efforts such as the source compatibility suite.  I apologize 
> for not providing more transparency in why moving to a forum was being 
> delayed.  Some things took longer than expected.
> 
> To be clear, the plan is to still move to Discourse, and with Swift 4 winding 
> down there is now bandwidth to focus on making the transition from mailing 
> lists to a forum.  As part of that transition, I’d like to get some feedback 
> from the community.
> 
> There has been some good conversations on this mailing list on how 
> swift-evolution can possibly evolve to better serve the needs of the 
> community.  I’m not talking about whether or not we use a mailing list or a 
> forum — that decision has been made.  Specifically, I’m talking about how a 
> forum could best be structured to organize discussions and allow everyone to 
> optimally participate.  In the move to Discourse, we have the opportunity 
> here to possibly do things a bit differently than we have been so far.
> 
> For example, here are some of the questions I’m thinking about how we should 
> be use a forum:
> 
> -  We currently have swift-evolution and swift-evolution-announce.  Should we 
> use a specific “category” in the forum for "proposals that are in active 
> review" — and possibly remove the need to have something like 
> swift-evolution-announce?  
> 
> - Should we have other topical areas to organize discussions?  If so, at what 
> granularity?
> 
> We can certainly figure out a lot of this over time, but I’d like some 
> feedback from the community now on things they’d like to see in how we 
> organize the swift-evolution forum based on experiences we’ve had with 
> swift-evolution since it was created.
> 
> Please chime in on this thread if you have feedback, and focus on keeping 
> this constructive.
> 
> Thanks,
> Ted
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Nicolas Fezans via swift-evolution]

Interesting figures. I will not try to discuss the generics, inlineable,
etc. there are certainly good observations and comments to make here, but
most people in this list know certainly more about it than I do.

I just want to point out that IMO a core math library for swift should
comply with the IEEE 754 standard in terms of precision, domain, and
special values. *On the long term*, it should ideally be able to use SIMD
instructions when applied to arrays/matrices or when the compiler can
autovectorize some loops.

On Thu, Aug 3, 2017 at 8:52 PM, Taylor Swift via swift-evolution <
swift-evolution@swift.org> wrote:

> In an effort to get this thread back on track, I tried implementing
> cos(_:) in pure generic Swift code, with the BinaryFloatingPoint protocol.
> It deviates from the _cos(_:) intrinsic by no more than
> 5.26362703423544e-11. Adding more terms to the approximation only has a
> small penalty to the performance for some reason.
>
> To make the benchmarks fair, and explore the idea of distributing a Math
> module without killing people on the cross-module optimization boundary, I
> enabled some of the unsafe compiler attributes. All of these benchmarks are
> cross-module calls, as if the math module were downloaded as a dependency
> in the SPM.
>
> == Relative execution time (lower is better) ==
>
> llvm intrinsic   :  3.133
> glibc cos()  :  3.124
>
> no attributes: 43.675
> with specialization  :  4.162
> with inlining:  3.108
> with inlining and specialization :  3.264
>
> As you can see, the pure Swift generic implementation actually beats the
> compiler intrinsic (and the glibc cos() but I guess they’re the same thing)
> when inlining is used, but for some reason generic specialization and
> inlining don’t get along very well.
>
> Here’s the source implementation. It uses a taylor series (!) which
> probably isn’t optimal but it does prove that cos() and sin() can be
> implemented as generics in pure Swift, be distributed as a module outside
> the stdlib, and still achieve competitive performance with the llvm
> intrinsics.
>
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> public
> func cos(_ x:F) -> F where F:BinaryFloatingPoint
> {
> let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
> quadrant:Int = Int(x * (2 / F.pi))
>
> switch quadrant
> {
> case 0:
> return  cos(on_first_quadrant:x)
> case 1:
> return -cos(on_first_quadrant: F.pi - x)
> case 2:
> return -cos(on_first_quadrant: x - F.pi)
> case 3:
> return -cos(on_first_quadrant: 2 * F.pi - x)
> default:
> fatalError("unreachable")
> }
> }
>
> @_versioned
> @_inlineable
> //@_specialize(where F == Float)
> //@_specialize(where F == Double)
> func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
> {
> let x2:F = x * x
> var y:F  = -0.00114707451267755432394
> for c:F in [0.2087675698165412591559,
>-0.00275573192239332256421489,
> 0.2480158730158702330045157,
>-0.00138880310186415,
> 0.0415319411988,
>-0.41637437,
> 0.99914771
> ]
> {
> y = x2 * y + c
> }
> return y
> }
>
> On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> It’s important to remember that computers are mathematical machines, and
>> some functions which are implemented in hardware on essentially every
>> platform (like sin/cos/etc) are definitely best implemented as compiler
>> intrinsics.
>>
>>
>> sin/cos/etc are implemented in software, not hardware. x86 does have the
>> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
>> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
>> and too inaccurate for serious use today. There are no analogous
>> instructions on ARM or PPC.
>>
>> – Steve
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

In an effort to get this thread back on track, I tried implementing cos(_:)
in pure generic Swift code, with the BinaryFloatingPoint protocol. It
deviates from the _cos(_:) intrinsic by no more than 5.26362703423544e-11.
Adding more terms to the approximation only has a small penalty to the
performance for some reason.

To make the benchmarks fair, and explore the idea of distributing a Math
module without killing people on the cross-module optimization boundary, I
enabled some of the unsafe compiler attributes. All of these benchmarks are
cross-module calls, as if the math module were downloaded as a dependency
in the SPM.

== Relative execution time (lower is better) ==

llvm intrinsic   :  3.133
glibc cos()  :  3.124

no attributes: 43.675
with specialization  :  4.162
with inlining:  3.108
with inlining and specialization :  3.264

As you can see, the pure Swift generic implementation actually beats the
compiler intrinsic (and the glibc cos() but I guess they’re the same thing)
when inlining is used, but for some reason generic specialization and
inlining don’t get along very well.

Here’s the source implementation. It uses a taylor series (!) which
probably isn’t optimal but it does prove that cos() and sin() can be
implemented as generics in pure Swift, be distributed as a module outside
the stdlib, and still achieve competitive performance with the llvm
intrinsics.

@_inlineable
//@_specialize(where F == Float)
//@_specialize(where F == Double)
public
func cos(_ x:F) -> F where F:BinaryFloatingPoint
{
let x:F = abs(x.remainder(dividingBy: 2 * F.pi)),
quadrant:Int = Int(x * (2 / F.pi))

switch quadrant
{
case 0:
return  cos(on_first_quadrant:x)
case 1:
return -cos(on_first_quadrant: F.pi - x)
case 2:
return -cos(on_first_quadrant: x - F.pi)
case 3:
return -cos(on_first_quadrant: 2 * F.pi - x)
default:
fatalError("unreachable")
}
}

@_versioned
@_inlineable
//@_specialize(where F == Float)
//@_specialize(where F == Double)
func cos(on_first_quadrant x:F) -> F where F:BinaryFloatingPoint
{
let x2:F = x * x
var y:F  = -0.00114707451267755432394
for c:F in [0.2087675698165412591559,
   -0.00275573192239332256421489,
0.2480158730158702330045157,
   -0.00138880310186415,
0.0415319411988,
   -0.41637437,
0.99914771
]
{
y = x2 * y + c
}
return y
}

On Thu, Aug 3, 2017 at 7:04 AM, Stephen Canon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> It’s important to remember that computers are mathematical machines, and
> some functions which are implemented in hardware on essentially every
> platform (like sin/cos/etc) are definitely best implemented as compiler
> intrinsics.
>
>
> sin/cos/etc are implemented in software, not hardware. x86 does have the
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow
> and too inaccurate for serious use today. There are no analogous
> instructions on ARM or PPC.
>
> – Steve
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Inconsistencies related to prepositions

[Austin Zheng via swift-evolution]

And likewise! I hope we can continue to work together to make Swift more
dynamic, expressive, and useful in the months and years going forward :).

Best,
Austin

On Thu, Aug 3, 2017 at 10:33 AM, Goffredo Marocchi 
wrote:

>
> Thank you for the long reply, I do agree that I could have been more
> constructive and what I said could have been more on point with the thread
> at hand and better argued. I do like a complete and well written rebuttal,
> chance for me to learn from it :).
>
> On Thu, Aug 3, 2017 at 5:14 PM, Austin Zheng 
> wrote:
>
>>
>>
>> On Thu, Aug 3, 2017 at 8:13 AM, Goffredo Marocchi 
>> wrote:
>>
>>> Because what is the current idiomatic Swift of today may not be the
>>> Swift of tomorrow if people are allowed to keep shaping it as it gets used
>>> in the real world. Ideas can be imported from other languages and today's
>>> ideas and philosophy are not dogmas.
>>>
>>
>> The problem I see with your email is that it does not contribute anything
>> to the discussion.
>>
>> - We _know_ Swift has an expressivity problem compared to Objective-C,
>> many people have made this point loud and clear.
>> - There are no useful concrete proposals or suggestions of design
>> directions expressed in this email besides the rehashing of a point that
>> has been made ad nauseaum on these lists, especially in places more
>> appropriate for it (e.g. in proposal reviews that involved strengthening
>> the type system).
>>
>>
>>> Swift does value expressiveness, see the use of argument labels which is
>>> perhaps more pervasive than it was in Objective-C (even more before the
>>> change in argument labels that hit closures and callbacks).
>>>
>>
>> Here is the crux of my disagreement with your email.
>>
>> Method naming conventions and static typing can be adjusted nearly
>> independently of one another, and bringing up the latter in a discussion
>> about the former is _not helpful_.
>>
>> You could remove Swift's type system tomorrow and still improve how
>> methods are named. In fact, Swift's current naming conventions are quite
>> suited for a dynamic language. You could also strengthen Swift's type
>> system and improve method naming conventions. The two do not march in
>> lockstep. "Expressiveness" is a huge, vague, and wide-reaching topic.
>> Claiming that static typing is an expressiveness concern and therefore that
>> complaining about it in a thread that deals with an almost completely
>> unrelated feature strikes me as disingenuous. Help me out here.
>>
>>
>>>
>>>
>>
>>> I do not want to add noise to useful discussions so please do not assume
>>> the worst in my statements, but I also do not think that the idea of "if
>>> you do not like , go back to your  country" has merit
>>> or is helpful to the evolution of the language.
>>>
>>
>> Please.
>>
>> The issue at hand is not "go back to your country", it is "use the right
>> tool for the job at hand".
>>
>> Engineering, like every field of human endeavor, has political elements,
>> but it is not itself a fundamentally political endeavor. This gross
>> anthropomorphization is beneath both you and I, and is better avoided for
>> the happiness of all.
>>
>> As for contributing to the evolution of the language, your post is not
>> the first of its quality, specific form, and sentiment that I've seen on
>> the list, but only the first that I've been moved to respond to. So if I
>> can steer future discussion in a more productive direction, I will consider
>> this email chain to be a net positive, even if I have to send out quite a
>> few more of these emails in reply :).
>>
>> With the utmost respect,
>> Austin
>>
>>
>>
>>
>>> On Thu, Aug 3, 2017 at 3:16 PM, Austin Zheng 
>>> wrote:
>>>
 If you want to use Objective-C you're free to use Objective-C, or more
 generally any of the wonderful languages that choose a different tradeoff
 regarding convenience over expressiveness. Otherwise, I'm not really sure
 what productive forward movement bringing up complaints about a fundamental
 philosophical underpinning of Swift that's not realistically going to
 change is supposed to achieve. As was mentioned in a message earlier this
 week, swift-evolution is a list to discuss making changes to the Swift
 language, not a list for ranting about things in Swift you don't like but
 cannot change.

 Regards,
 Austin

 On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evolution <
 swift-evolution@swift.org> wrote:


 Sent from my iPhone

 On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution <
 swift-evolution@swift.org> wrote:

 On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:

 Brent had a draft proposal to revise the names of collection methods to
 improve the situation here. There is room for improvement.

Re: [swift-evolution] Inconsistencies related to prepositions

[Goffredo Marocchi via swift-evolution]

Thank you for the long reply, I do agree that I could have been more
constructive and what I said could have been more on point with the thread
at hand and better argued. I do like a complete and well written rebuttal,
chance for me to learn from it :).

On Thu, Aug 3, 2017 at 5:14 PM, Austin Zheng  wrote:

>
>
> On Thu, Aug 3, 2017 at 8:13 AM, Goffredo Marocchi 
> wrote:
>
>> Because what is the current idiomatic Swift of today may not be the Swift
>> of tomorrow if people are allowed to keep shaping it as it gets used in the
>> real world. Ideas can be imported from other languages and today's ideas
>> and philosophy are not dogmas.
>>
>
> The problem I see with your email is that it does not contribute anything
> to the discussion.
>
> - We _know_ Swift has an expressivity problem compared to Objective-C,
> many people have made this point loud and clear.
> - There are no useful concrete proposals or suggestions of design
> directions expressed in this email besides the rehashing of a point that
> has been made ad nauseaum on these lists, especially in places more
> appropriate for it (e.g. in proposal reviews that involved strengthening
> the type system).
>
>
>> Swift does value expressiveness, see the use of argument labels which is
>> perhaps more pervasive than it was in Objective-C (even more before the
>> change in argument labels that hit closures and callbacks).
>>
>
> Here is the crux of my disagreement with your email.
>
> Method naming conventions and static typing can be adjusted nearly
> independently of one another, and bringing up the latter in a discussion
> about the former is _not helpful_.
>
> You could remove Swift's type system tomorrow and still improve how
> methods are named. In fact, Swift's current naming conventions are quite
> suited for a dynamic language. You could also strengthen Swift's type
> system and improve method naming conventions. The two do not march in
> lockstep. "Expressiveness" is a huge, vague, and wide-reaching topic.
> Claiming that static typing is an expressiveness concern and therefore that
> complaining about it in a thread that deals with an almost completely
> unrelated feature strikes me as disingenuous. Help me out here.
>
>
>>
>>
>
>> I do not want to add noise to useful discussions so please do not assume
>> the worst in my statements, but I also do not think that the idea of "if
>> you do not like , go back to your  country" has merit
>> or is helpful to the evolution of the language.
>>
>
> Please.
>
> The issue at hand is not "go back to your country", it is "use the right
> tool for the job at hand".
>
> Engineering, like every field of human endeavor, has political elements,
> but it is not itself a fundamentally political endeavor. This gross
> anthropomorphization is beneath both you and I, and is better avoided for
> the happiness of all.
>
> As for contributing to the evolution of the language, your post is not the
> first of its quality, specific form, and sentiment that I've seen on the
> list, but only the first that I've been moved to respond to. So if I can
> steer future discussion in a more productive direction, I will consider
> this email chain to be a net positive, even if I have to send out quite a
> few more of these emails in reply :).
>
> With the utmost respect,
> Austin
>
>
>
>
>> On Thu, Aug 3, 2017 at 3:16 PM, Austin Zheng 
>> wrote:
>>
>>> If you want to use Objective-C you're free to use Objective-C, or more
>>> generally any of the wonderful languages that choose a different tradeoff
>>> regarding convenience over expressiveness. Otherwise, I'm not really sure
>>> what productive forward movement bringing up complaints about a fundamental
>>> philosophical underpinning of Swift that's not realistically going to
>>> change is supposed to achieve. As was mentioned in a message earlier this
>>> week, swift-evolution is a list to discuss making changes to the Swift
>>> language, not a list for ranting about things in Swift you don't like but
>>> cannot change.
>>>
>>> Regards,
>>> Austin
>>>
>>> On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Brent had a draft proposal to revise the names of collection methods to
>>> improve the situation here. There is room for improvement.
>>>
>>>
>>> It didn't change `remove(at:)`, though. (Well, it might have affected
>>> its return value or something, I don't remember.) It mostly addressed the
>>> `dropLast()`, `prefix(_:)` etc. calls.
>>>
>>> To respond to the original post:
>>>
>>> Some of the APIs you cite are not very well named, but I think your
>>> diagnosis is incorrect and so your prescription 

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Itai Ferber via swift-evolution]

I just mentioned this in my other email, but to point out here: the reason this 
works in your case is because you adopt these methods as static funcs and can 
reasonably rely on subclasses of NSData, NSNumber, NSString, etc. to do the 
right thing because of work done behind the scenes in the ObjC implementations 
of these classes (and because we’ve got established subclassing requirements on 
these methods — all subclasses of these classes are going to look approximately 
the same without doing anything crazy).

This would not work for Codable in the general case, however, where subclasses 
likely need to add additional storage, properties, encoded representations, 
etc., without equivalent requirements, either via additional protocols or 
conventions.

> On Aug 3, 2017, at 1:50 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> 
>> Le 3 août 2017 à 02:09, Jordan Rose via swift-evolution 
>> > a écrit :
>> 
>> P.S. There's a reason why Decodable uses an initializer instead of a 
>> factory-like method on the type but I can't remember what it is right now. I 
>> think it's something to do with having the right result type, which would 
>> have to be either 'Any' or an associated type if it wasn't just 'Self'. (And 
>> if it is 'Self' then it has all the same problems as an initializer and 
>> would require extra syntax.) Itai would know for sure.
> 
> For anyone interested, factory methods *can* retroactivaly be added to 
> existing classes. This is how the SQLite library GRDB.swift is able to decode 
> classes hierarchies like NSString, NSNumber, NSDecimalNumber, etc. from 
> SQLite values:
> 
> The protocol for types that can instantiate from SQLite values has a factory 
> method:
> 
> public protocol DatabaseValueConvertible {
> /// Returns a value initialized from *dbValue*, if possible.
> static func fromDatabaseValue(_ dbValue: DatabaseValue) -> Self?
> }
> 
> Having Foundation classes implement it uses various techniques:
> 
> 1. "Casting" (Data to NSData, or NSDate to Date, depending on which type 
> provides the root conformance)
> 
> // Workaround Swift inconvenience around factory methods of non-final 
> classes
> func cast(_ value: T) -> U? {
> return value as? U
> }
> 
> extension NSData : DatabaseValueConvertible {
> public static func fromDatabaseValue(_ dbValue: DatabaseValue) -> 
> Self? {
> // Use Data conformance
> guard let data = Data.fromDatabaseValue(dbValue) else {
> return nil
> }
> return cast(data)
> }
> }
> 
> // Derives Date conformance from NSDate, for example
> extension ReferenceConvertible where Self: DatabaseValueConvertible, 
> Self.ReferenceType: DatabaseValueConvertible {
> public static func fromDatabaseValue(_ dbValue: DatabaseValue) -> 
> Self? {
> return ReferenceType.fromDatabaseValue(dbValue).flatMap { 
> cast($0) }
> }
> }
> 
> 
> 2. Using magic Foundation initializers (magic because the code below compiles 
> even if those are not *required* initializers). Works for NSNumber, 
> NSDecimalNumber, NSString:
> 
> extension NSNumber : DatabaseValueConvertible {
> public static func fromDatabaseValue(_ dbValue: DatabaseValue) -> 
> Self? {
> switch dbValue.storage {
> case .int64(let int64):
> return self.init(value: int64)
> case .double(let double):
> return self.init(value: double)
> default:
> return nil
> }
> }
> }
> 
> extension NSString : DatabaseValueConvertible {
> public static func fromDatabaseValue(_ dbValue: DatabaseValue) -> 
> Self? {
> // Use String conformance
> guard let string = String.fromDatabaseValue(dbValue) else {
> return nil
> }
> return self.init(string: string)
> }
> }
> 
> The magic about Foundation initializers above makes me doubt that this 
> technique is general enough for Decodable to profit from it, though. Yes it 
> runs on Linux, so I'm not even sure if objc runtime is required or not. I'm 
> clueless ???
> 
> Gwendal Roué
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Itai Ferber via swift-evolution]

Thanks for putting these thoughts together, Jordan! Some additional comments 
inline.

> On Aug 2, 2017, at 5:08 PM, Jordan Rose  wrote:
> 
> David Hart recently asked on Twitter 
>  if there was a good 
> way to add Decodable support to somebody else's class. The short answer is 
> "no, because you don't control all the subclasses", but David already 
> understood that and wanted to know if there was anything working to mitigate 
> the problem. So I decided to write up a long email about it instead. (Well, 
> actually I decided to write a short email and then failed at doing so.)
> 
> The Problem
> 
> You can add Decodable to someone else's struct today with no problems:
> 
> extension Point: Decodable {
>   enum CodingKeys: String, CodingKey {
> case x
> case y
>   }
>   public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> let x = try container.decode(Double.self, forKey: .x)
> let y = try container.decode(Double.self, forKey: .y)
> self.init(x: x, y: y)
>   }
> }
> 
> But if Point is a (non-final) class, then this gives you a pile of errors:
> 
> - init(from:) needs to be 'required' to satisfy a protocol requirement. 
> 'required' means the initializer can be invoked dynamically on subclasses. 
> Why is this important? Because someone might write code like this:
> 
> func decodeMe() -> Result {
>   let decoder = getDecoderFromSomewhere()
>   return Result(from: decoder)
> }
> let specialPoint: VerySpecialSubclassOfPoint = decodeMe()
> 
> …and the compiler can't stop them, because VerySpecialSubclassOfPoint is a 
> Point, and Point is Decodable, and therefore VerySpecialSubclassOfPoint is 
> Decodable. A bit more on this later, but for now let's say that's a sensible 
> requirement.
> 
> - init(from:) also has to be a 'convenience' initializer. That one makes 
> sense too—if you're outside the module, you can't necessarily see private 
> properties, and so of course you'll have to call another initializer that can.
> 
> But once it's marked 'convenience' and 'required' we get "'required' 
> initializer must be declared directly in class 'Point' (not in an 
> extension)", and that defeats the whole purpose. Why this restriction?
> 
> 
> The Semantic Reason
> 
> The initializer is 'required', right? So all subclasses need to have access 
> to it. But the implementation we provided here might not make sense for all 
> subclasses—what if VerySpecialSubclassOfPoint doesn't have an 'init(x:y:)' 
> initializer? Normally, the compiler checks for this situation and makes the 
> subclass reimplement the 'required' initializer…but that only works if the 
> 'required' initializers are all known up front. So it can't allow this new 
> 'required' initializer to go by, because someone might try to call it 
> dynamically on a subclass. Here's a dynamic version of the code from above:
> 
> func decodeDynamic(_ pointType: Point.Type) -> Point {
>   let decoder = getDecoderFromSomewhere()
>   return pointType.init(from: decoder)
> }
> let specialPoint = decodeDynamic(VerySpecialSubclassOfPoint.self)
> 
> 
> The Implementation Reason
> 
> 'required' initializers are like methods: they may require dynamic dispatch. 
> That means that they get an entry in the class's dynamic dispatch table, 
> commonly known as its vtable. Unlike Objective-C method tables, vtables 
> aren't set up to have entries arbitrarily added at run time.
> 
> (Aside: This is one of the reasons why non-@objc methods in Swift extensions 
> can't be overridden; if we ever lift that restriction, it'll be by using a 
> separate table and a form of dispatch similar to objc_msgSend. I sent a 
> proposal to swift-evolution about this last year but there wasn't much 
> interest.)
> 
> 
> The Workaround
> 
> Today's answer isn't wonderful, but it does work: write a wrapper struct that 
> conforms to Decodable instead:
> 
> struct DecodedPoint: Decodable {
>   var value: Point
>   enum CodingKeys: String, CodingKey {
> case x
> case y
>   }
>   public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> let x = try container.decode(Double.self, forKey: .x)
> let y = try container.decode(Double.self, forKey: .y)
> self.value = Point(x: x, y: y)
>   }
> }
> 
> This doesn't have any of the problems with inheritance, because it only 
> handles the base class, Point. But it makes everywhere else a little less 
> convenient—instead of directly encoding or decoding Point, you have to use 
> the wrapper, and that means no implicitly-generated Codable implementations 
> either.
> 
> I'm not going to spend more time talking about this, but it is the officially 
> recommended answer at the moment. You can also just have all your own types 
> that contain points manually decode the 'x' and 'y' values and then construct 
> a Point from that.

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

On Thu, Aug 3, 2017 at 3:21 AM, Tino Heth <2...@gmx.de> wrote:

>
> You're welcome to join me in my endeavor to create a math library. I'd bet
> Karoly feels the same way about his project.
>
> See, exactly this is the big problem we are facing here — probably not in
> your specific case, but in general:
> It's not very appealing for most people to contribute to a small library
> that's rarely known, instead of starting their own project to collect
> github stars...
>
> - Tino
>
>
I agree. People tend to ignore the social factors present here and assume
that developers act perfectly rationally, then wonder why Swift library
support is so horrifically fragmented.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Taylor Swift via swift-evolution]

I don’t think we should be designing interfaces based off of what pure
mathematicians write. Scientists aren’t the only people who use sin(x).
It’s better to go with the “common sense” behavior than the esoteric
academic notation. And for the record, I think Matrix.map(sin(_:)) is the
best and most clear interface for elementwise sin.

On Thu, Aug 3, 2017 at 7:00 AM, Stephen Canon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I am of course not talking about a syntax sugar to call a sin or cos
> function, but rather to manipulate other objects such as N-dimensional
> matrices, defining maths functions that can take such matrices as argument
> e.g. sin(A) with A as matrix produces a matrix of the same size where all
> elements are the sinus values of the elements of A (sorry but things like
> this calling map() with 'sin' looks quite ugly for scientists).
>
>
> You’re on very shaky ground here. It is not at all obvious that sin(A)
> should be the “elementwise” sine that you suggest, and not the matrix sine
> (defined by plugging A into the power series for sine, which is globally
> convergent). Depending on what branch of science/math you come from, one of
> these is “obviously” the right answer, but I assure you that it’s very much
> not obvious.
>
> Yes, we want libraries to build this sort of thing to exist.
>
> No, it’s not clear what the “right” way to expose some of these operations
> in the language/library are.
>
> It is better to be verbose but correct than to be terse and cause bugs.
>
> – Steve
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Jacob Williams via swift-evolution]

There’s also a PureSwift organization of GitHub that has several Swift PM 
packages built specifically with Linux support in mind

https://github.com/PureSwift 

It looks like it’s along the lines of SwiftBreezy, but it hasn’t died out…yet.

At the same time, this may just be another example of how without an Apple 
“backed”/supported repo, the community is very likely to become more and more 
fragmented as more and more people implement the same few frameworks with minor 
variations/improvements.

> On Aug 3, 2017, at 5:04 AM, Stephen Canon via swift-evolution 
>  wrote:
> 
>> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> It’s important to remember that computers are mathematical machines, and 
>> some functions which are implemented in hardware on essentially every 
>> platform (like sin/cos/etc) are definitely best implemented as compiler 
>> intrinsics.
> 
> sin/cos/etc are implemented in software, not hardware. x86 does have the 
> FSIN/FCOS instructions, but (almost) no one actually uses them to implement 
> the sin( ) and cos( ) functions; they are a legacy curiosity, both too slow 
> and too inaccurate for serious use today. There are no analogous instructions 
> on ARM or PPC.
> 
> – Steve
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] RFC: structuring forums for best use for swift-evolution

[Félix Fischer via swift-evolution]

Hi! I hope I sent this email correctly and it entered the RFC thread
started by Ted.

My pitch: what about timeline of thread as a category? Like this:
- Short term: for current release of Swift, aka 4.1 after 4.0 is released.
- Mid term: for next release of Swift, aka 4.0 now, because 3.x is the
current release.
- Long term: for releases far away. Pertaining Swift 5.0 now, or Swift 6.0,
7.0 and such.

I think it’s at least useful as a divider between different topics, because
depending on the timeline, the planning process and base priority of the
threads should be different.

— Félix
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Slava Pestov via swift-evolution]

> On Aug 2, 2017, at 10:48 PM, David Hart  wrote:
> 
> Somewhat related: I have a similar problem in a project where I need two 
> different Codable conformances for a type: one for coding/decoding from/to 
> JSON, and another one for coding/decoding from/to a database row. The keys 
> and formatting are not identical. The only solution around that for now is 
> separate types, which can be sub-optimal from a performance point of view.

Actually if the wrapper types are structs with a single field, their use should 
not introduce any additional overhead at runtime.

Slava
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Inconsistencies related to prepositions

[Austin Zheng via swift-evolution]

On Thu, Aug 3, 2017 at 8:13 AM, Goffredo Marocchi  wrote:

> Because what is the current idiomatic Swift of today may not be the Swift
> of tomorrow if people are allowed to keep shaping it as it gets used in the
> real world. Ideas can be imported from other languages and today's ideas
> and philosophy are not dogmas.
>

The problem I see with your email is that it does not contribute anything
to the discussion.

- We _know_ Swift has an expressivity problem compared to Objective-C, many
people have made this point loud and clear.
- There are no useful concrete proposals or suggestions of design
directions expressed in this email besides the rehashing of a point that
has been made ad nauseaum on these lists, especially in places more
appropriate for it (e.g. in proposal reviews that involved strengthening
the type system).


> Swift does value expressiveness, see the use of argument labels which is
> perhaps more pervasive than it was in Objective-C (even more before the
> change in argument labels that hit closures and callbacks).
>

Here is the crux of my disagreement with your email.

Method naming conventions and static typing can be adjusted nearly
independently of one another, and bringing up the latter in a discussion
about the former is _not helpful_.

You could remove Swift's type system tomorrow and still improve how methods
are named. In fact, Swift's current naming conventions are quite suited for
a dynamic language. You could also strengthen Swift's type system and
improve method naming conventions. The two do not march in lockstep.
"Expressiveness" is a huge, vague, and wide-reaching topic. Claiming that
static typing is an expressiveness concern and therefore that complaining
about it in a thread that deals with an almost completely unrelated feature
strikes me as disingenuous. Help me out here.


>
>

> I do not want to add noise to useful discussions so please do not assume
> the worst in my statements, but I also do not think that the idea of "if
> you do not like , go back to your  country" has merit
> or is helpful to the evolution of the language.
>

Please.

The issue at hand is not "go back to your country", it is "use the right
tool for the job at hand".

Engineering, like every field of human endeavor, has political elements,
but it is not itself a fundamentally political endeavor. This gross
anthropomorphization is beneath both you and I, and is better avoided for
the happiness of all.

As for contributing to the evolution of the language, your post is not the
first of its quality, specific form, and sentiment that I've seen on the
list, but only the first that I've been moved to respond to. So if I can
steer future discussion in a more productive direction, I will consider
this email chain to be a net positive, even if I have to send out quite a
few more of these emails in reply :).

With the utmost respect,
Austin




> On Thu, Aug 3, 2017 at 3:16 PM, Austin Zheng 
> wrote:
>
>> If you want to use Objective-C you're free to use Objective-C, or more
>> generally any of the wonderful languages that choose a different tradeoff
>> regarding convenience over expressiveness. Otherwise, I'm not really sure
>> what productive forward movement bringing up complaints about a fundamental
>> philosophical underpinning of Swift that's not realistically going to
>> change is supposed to achieve. As was mentioned in a message earlier this
>> week, swift-evolution is a list to discuss making changes to the Swift
>> language, not a list for ranting about things in Swift you don't like but
>> cannot change.
>>
>> Regards,
>> Austin
>>
>> On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> Sent from my iPhone
>>
>> On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Brent had a draft proposal to revise the names of collection methods to
>> improve the situation here. There is room for improvement.
>>
>>
>> It didn't change `remove(at:)`, though. (Well, it might have affected its
>> return value or something, I don't remember.) It mostly addressed the
>> `dropLast()`, `prefix(_:)` etc. calls.
>>
>> To respond to the original post:
>>
>> Some of the APIs you cite are not very well named, but I think your
>> diagnosis is incorrect and so your prescription isn't going to help.
>>
>> The reason for this is, whenever a preposition is used in English, it
>> almost always takes a dyadic form, relating a subject to the preposition's
>> object. The two most common dyadic formats are:
>>
>> * [ ]*
>>  [ ] crossed the street.
>>
>> *[ <** object of preposition**>] *
>> [ ],  can hear you scream.
>> [ ] are .
>>
>> Now, in Objective C through Swift 1 and 2, prepositions' dyadic nature
>> were generally respected in method signatures. However, 

[swift-evolution] Fwd: Inconsistencies related to prepositions

[Goffredo Marocchi via swift-evolution]

-- Forwarded message --
From: Goffredo Marocchi 
Date: Thu, Aug 3, 2017 at 4:13 PM
Subject: Re: [swift-evolution] Inconsistencies related to prepositions
To: Austin Zheng 


Because what is the current idiomatic Swift of today may not be the Swift
of tomorrow if people are allowed to keep shaping it as it gets used in the
real world. Ideas can be imported from other languages and today's ideas
and philosophy are not dogmas.
Swift does value expressiveness, see the use of argument labels which is
perhaps more pervasive than it was in Objective-C (even more before the
change in argument labels that hit closures and callbacks).

I do not want to add noise to useful discussions so please do not assume
the worst in my statements, but I also do not think that the idea of "if
you do not like , go back to your  country" has merit
or is helpful to the evolution of the language.

On Thu, Aug 3, 2017 at 3:16 PM, Austin Zheng  wrote:

> If you want to use Objective-C you're free to use Objective-C, or more
> generally any of the wonderful languages that choose a different tradeoff
> regarding convenience over expressiveness. Otherwise, I'm not really sure
> what productive forward movement bringing up complaints about a fundamental
> philosophical underpinning of Swift that's not realistically going to
> change is supposed to achieve. As was mentioned in a message earlier this
> week, swift-evolution is a list to discuss making changes to the Swift
> language, not a list for ranting about things in Swift you don't like but
> cannot change.
>
> Regards,
> Austin
>
> On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Sent from my iPhone
>
> On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Brent had a draft proposal to revise the names of collection methods to
> improve the situation here. There is room for improvement.
>
>
> It didn't change `remove(at:)`, though. (Well, it might have affected its
> return value or something, I don't remember.) It mostly addressed the
> `dropLast()`, `prefix(_:)` etc. calls.
>
> To respond to the original post:
>
> Some of the APIs you cite are not very well named, but I think your
> diagnosis is incorrect and so your prescription isn't going to help.
>
> The reason for this is, whenever a preposition is used in English, it
> almost always takes a dyadic form, relating a subject to the preposition's
> object. The two most common dyadic formats are:
>
> * [ ]*
>  [ ] crossed the street.
>
> *[ <** object of preposition**>] *
> [ ],  can hear you scream.
> [ ] are .
>
> Now, in Objective C through Swift 1 and 2, prepositions' dyadic nature
> were generally respected in method signatures. However, Swift 3's migration
> of the preposition inside the parentheses also seems to have been
> accompanied by the stripping away of either the subject, the prepositional
> object, or both—according to no discernible pattern. For example:
>
> (1) CloudKit:
>
> old: myCKDatabase.fetchRecordWithID(recordID)
> new: myCKDatabase.fetch(withRecordID: recordID)
> *(subject "Record" got removed)*
>
>
> (2) String:
>
> old: myString.capitalizedStringWithLocale(_: myLocale)
> new: myString.capitalized(with: myLocale)
> *(subject "String" and prep. object "Locale" both got removed)*
>
>
> (3) Dictionary:
>
> old: myDict.removeAtIndex(myIndex)
> new: myDict.remove(at: myIndex)
> *(subject "element" already missing from both; prep. object "Index" got
> removed)*
>
>
> The thing is, the subjects and prepositional objects *are* present in all
> of these—they are the parameters and targets of the calls.
>
> In your own example, you say "In space, no one can hear you scream", not
> "In location space, group-of-people no one can hear you scream". So why is
> it a problem that we say "myString, capitalized with myLocale" instead of
> "myString, string capitalized with locale myLocale"? These are redundancies
> that we would never tolerate in natural language; I don't see why you think
> code should be different.
>
> (4) Date:
>
> old: myDate.timeIntervalSinceDate(myDate)
> new: myDate.timeIntervalSince(date: myDate)
> *(subject "timeInterval" and object "Date" both still present; but oddly,
> preposition "since" got left outside of the parentheses)*
>
>
> This is actually inaccurate—the parameter to `timeIntervalSince(_:)` is
> unlabeled, so it's:
>
> new: myDate.timeIntervalSince(myDate)
>
> (5) Array:
>
> old: myArray.forEach({ thing in code})
>
> new: myArray.forEach() { thing in //code }
>
> *(preposition “for” is outside of the parentheses)*
>
>
> Yes, because the preposition does not apply to the parameter—it applies to
> the operation as a whole. I'll have more to say on this in a moment.
>
> The 

Re: [swift-evolution] Inconsistencies related to prepositions

[Austin Zheng via swift-evolution]

If you want to use Objective-C you're free to use Objective-C, or more 
generally any of the wonderful languages that choose a different tradeoff 
regarding convenience over expressiveness. Otherwise, I'm not really sure what 
productive forward movement bringing up complaints about a fundamental 
philosophical underpinning of Swift that's not realistically going to change is 
supposed to achieve. As was mentioned in a message earlier this week, 
swift-evolution is a list to discuss making changes to the Swift language, not 
a list for ranting about things in Swift you don't like but cannot change.

Regards,
Austin

> On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 
> Sent from my iPhone
> 
> On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution 
> > wrote:
> 
>>> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> Brent had a draft proposal to revise the names of collection methods to 
>>> improve the situation here. There is room for improvement.
>> 
>> It didn't change `remove(at:)`, though. (Well, it might have affected its 
>> return value or something, I don't remember.) It mostly addressed the 
>> `dropLast()`, `prefix(_:)` etc. calls.
>> 
>> To respond to the original post:
>> 
>> Some of the APIs you cite are not very well named, but I think your 
>> diagnosis is incorrect and so your prescription isn't going to help.
>> 
>>> The reason for this is, whenever a preposition is used in English, it 
>>> almost always takes a dyadic form, relating a subject to the preposition's 
>>> object. The two most common dyadic formats are:
>>> 
>>>  [ ]
>>>  [ ] crossed the street. 
>>> 
>>> [ < object of preposition>] 
>>> [ ],  can hear you scream.
>>> [ ] are .
>>> 
>>> Now, in Objective C through Swift 1 and 2, prepositions' dyadic nature were 
>>> generally respected in method signatures. However, Swift 3's migration of 
>>> the preposition inside the parentheses also seems to have been accompanied 
>>> by the stripping away of either the subject, the prepositional object, or 
>>> both—according to no discernible pattern. For example: 
>>> 
>>> (1) CloudKit:
>>> 
>>> old: myCKDatabase.fetchRecordWithID(recordID)
>>> new: myCKDatabase.fetch(withRecordID: recordID)
>>> (subject "Record" got removed)
>>> 
>>> (2) String:
>>> 
>>> old: myString.capitalizedStringWithLocale(_: myLocale)
>>> new: myString.capitalized(with: myLocale)
>>> (subject "String" and prep. object "Locale" both got removed)
>>> 
>>> (3) Dictionary:
>>> 
>>> old: myDict.removeAtIndex(myIndex)
>>> new: myDict.remove(at: myIndex)
>>> (subject "element" already missing from both; prep. object "Index" got 
>>> removed)
>> 
>> The thing is, the subjects and prepositional objects *are* present in all of 
>> these—they are the parameters and targets of the calls. 
>> 
>> In your own example, you say "In space, no one can hear you scream", not "In 
>> location space, group-of-people no one can hear you scream". So why is it a 
>> problem that we say "myString, capitalized with myLocale" instead of 
>> "myString, string capitalized with locale myLocale"? These are redundancies 
>> that we would never tolerate in natural language; I don't see why you think 
>> code should be different.
>> 
>>> (4) Date:
>>> 
>>> old: myDate.timeIntervalSinceDate(myDate)
>>> new: myDate.timeIntervalSince(date: myDate)
>>> (subject "timeInterval" and object "Date" both still present; but oddly, 
>>> preposition "since" got left outside of the parentheses)
>> 
>> This is actually inaccurate—the parameter to `timeIntervalSince(_:)` is 
>> unlabeled, so it's:
>> 
>>  new: myDate.timeIntervalSince(myDate)
>> 
>>> (5) Array:
>>> 
>>> old: myArray.forEach({ thing in code})
>>> new: myArray.forEach() { thing in //code }
>>> (preposition “for” is outside of the parentheses)
>> 
>> Yes, because the preposition does not apply to the parameter—it applies to 
>> the operation as a whole. I'll have more to say on this in a moment.
>> 
>>> The inconsistency between the examples is shown in the bold text of each 
>>> example, but lets go over why this matters. It matters because any language 
>>> is easier to learn the more consistently it sticks to its own rules.
>> 
>> 
>> This is true, but you aren't just proposing sticking more closely to our 
>> existing standards—you're proposing *changing* our standards. And I don't 
>> think the changes you propose are an improvement. In fact, I'd say each of 
>> these examples is worse:
>> 
>>> (1) myCKDatabase.fetchRecord(withRecordID:)
>> 
>> "Fetch record with record ID"? I mean, you could at least remove the 
>> `Record` before `ID`. What other ID do you suppose it would be?
>> 
>> I *can* see the case for going back to `fetchRecord` instead of just 
>> `fetch`, though. On the other 

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Tino Heth via swift-evolution]

> I’m not saying that tuple member names are “true integers” (although, with 
> Reflection…). I understood that, semantically, the reason we refer to 
> elements .0, .1 and .2 of a tuple because that’s their name, not necessarily 
> because its their position in the tuple. My point is that for a fixed-size 
> array like a [3; Double] vector, because you know what to expect at each 
> location, those indices are *both* ordinal *and* nominal. Subscripting [0] or 
> [1] from that FSA has the same conceptual meaning as accessing .x or .y on an 
> equivalent struct. What I’m trying to say is: for a FSA, the index *is* the 
> member name, just like the declaration-order number is for tuples.
I think one important aspect of an array is that the slots don't have a name at 
all...

> I think the difference is that, for a fixed-size Array, the absolute 
> positions also generally have external meaning which is known to the 
> programmer but not reflected in the type-system. For example, that a [3; 
> Double] vector is supposed to be interpreted as (x, y, z) components, in that 
> order.
> 
> We can do better than to expose a 3-element vector as a list of 3 unlabelled 
> values. Or even a n-dimensional matrix just as a series of numbers.
I don't think we can — because a matrix is nothing but a bunch of numbers.
How would you name the elements in 600 × 2000 matrix?
Shorthands like x, y, z are only used in a very restricted environment that has 
little to do with real math.

> A better system may require meta-programming features we don’t support yet, 
> and that’s fine, but I would really like us to focus on the actual use-cases 
> of FSAs and to consider ways of making those great, rather than checking off 
> a feature that we have to have ‘just because’.
As I said: I don't think there is a better system, but what features should 
that be?

> I remember that in the first Swift beta, you were allowed to mutate a “let” 
> Array as long as you didn’t change its length. The community didn’t like it 
> and things moved to COW instead.
… and it made a lot of sense, because "can't be resized" is not a very useful 
feature when you can't reason about the size, and "can't be modified at all" 
helps a lot.
Fixed-size arrays are completely different when they expose their size to the 
type checker.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Karl Wagner via swift-evolution]

> On 3. Aug 2017, at 07:26, John McCall  wrote:
> 
>> On Aug 3, 2017, at 12:45 AM, Daryle Walker > > wrote:
>>> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution 
>>> > wrote:
>>> 
>>> I’m -1 on adding a fixed-sized Array type.
>>> 
>>> It goes back to something which I remember reading from John McCall earlier 
>>> this week but can’t find any more: about tuple indices being nominal and 
>>> not ordinal. How do fixed-size Arrays differ? Are their indexes truly not 
>>> nominal?
>> 
>> I think he meant that the numbered names for tuple members were originally 
>> (?) there because the Swift authors didn’t mandate each member needing a 
>> label, so there needed some way to refer to unnamed members. Note that 
>> numbered names are not true integer variables, not even useable as such. 
>> Array indexes are programmable objects; algorithms on the indexes is how we 
>> select array subsets to apply algorithms

I’m not saying that tuple member names are “true integers” (although, with 
Reflection…). I understood that, semantically, the reason we refer to elements 
.0, .1 and .2 of a tuple because that’s their name, not necessarily because its 
their position in the tuple. My point is that for a fixed-size array like a [3; 
Double] vector, because you know what to expect at each location, those indices 
are *both* ordinal *and* nominal. Subscripting [0] or [1] from that FSA has the 
same conceptual meaning as accessing .x or .y on an equivalent struct. What I’m 
trying to say is: for a FSA, the index *is* the member name, just like the 
declaration-order number is for tuples.

> 
> Yes, essentially.  I was making this argument on a slightly higher level, 
> just thinking about the meaning of values separate from any syntax.
> 
> A fixed-sized array is still fundamentally an array: it's a sequence of 
> homogenous elements, where relative positions generally have some level of 
> meaning.  In an array like [A,B,C,D], it's probably *significant* that A 
> comes first and that C comes before D.  On some level, if it wasn't true that 
> the order was significant, it wouldn't "really" be an array, it would be a 
> set (or multiset) being represented using an array.

I think the difference is that, for a fixed-size Array, the absolute positions 
also generally have external meaning which is known to the programmer but not 
reflected in the type-system. For example, that a [3; Double] vector is 
supposed to be interpreted as (x, y, z) components, in that order.

We can do better than to expose a 3-element vector as a list of 3 unlabelled 
values. Or even a n-dimensional matrix just as a series of numbers. A better 
system may require meta-programming features we don’t support yet, and that’s 
fine, but I would really like us to focus on the actual use-cases of FSAs and 
to consider ways of making those great, rather than checking off a feature that 
we have to have ‘just because’.

> 
> In contrast, a tuple is more like a jumble of independent values, ordered 
> only because in this benighted world we can't really write them down at the 
> same time. If you know someone's name and age, and you have to scribble them 
> both down on a piece of paper, it doesn't really change anything which one 
> you write first.  At most there's some arbitrary convention for the order, 
> like putting x before y in Cartesian coordinates.
> 
> We can choose different types for different purposes because they convey 
> different things about the values they store.  Isomorphism is not meaning.
> 
>>> The difference between a fixed-size array and the dynamically-sized Array 
>>> we already have is that the programmer expects specific data at each 
>>> element. Maybe it’s elements of a vector or matrix, or some other 
>>> structure, but in general I think that constraints about the size/shape of 
>>> the sequence implies expectations about what you’re going to find at each 
>>> location. Maybe you would normally write a struct for it, but it’s not 
>>> worth writing out. In that sense, how is it different from a homogenous 
>>> tuple?
>> 
>> I’m not sure what you mean here. How do elements of dynamically-sized arrays 
>> not have expectations?
>> 
>> The big innovation arrays (and loops) brought was no longer having a 
>> per-sub-object declaration/command for elements. Just tweak a number.
>> 
>> I’m not good at explicit explanations, so having to justify adding a type 
>> that’s been around for a long time (at least FORTRAN 4+ decades ago) an 
>> almost every systems programming language has is frustrating. I thought the 
>> desire would be obvious; if there were FSAs in Swift 1, would there be any 
>> “just slap Collection on tuples and be done with it” suggestions now? It 
>> doesn’t help that I still don’t know why FSAs where skipped in Swift 1; did 
>> they forget or was there some high-level 

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Tino Heth via swift-evolution]

> Honestly, a lot of this still applies.  I would like to see fixed-sized 
> arrays in the language eventually, but they are not going to become a 
> priority, because there's a lot of other stuff that is more important to work 
> on.
I guess it all depends on the the future focus of the language:
Objective-C has always been a poor choice for math, but Swift could really 
shine in this area if it would be possible to use Ints as generic parameters...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Tino Heth via swift-evolution]

Hi Daryle,

I think we agree a lot on the importance of fixed-size arrays, but have a 
different opinion on which aspect is the most valuable… (so we now only have to 
agree that mine is better ;-) ;-)
My motivation for FSA is safety and convenience:
I want to iterate over C arrays in a straightforward way, but primarily, I 
don't want to accidentally multiply a vector of size 3 with a 2×2 matrix.
Of course, fast is cool, but I don't expect to suffer from bad performance 
because of implementation details like how, where and when memory allocation 
happens.
Your focus, on the other hand, seems to be performance:
You don't want to give guarantees about the order because of (hypothetical?) 
optimisations that could be blocked by that, and avoid initialisation overhead.

You brought "withUnsafeFlattening" to the table to add convenience, but I think 
that is the wrong direction:
Safe should be default, and it's quite common that you have to live with 
"unsafe" when you need "fast".

As you don't want to confirm to Sequence at all, it shouldn't bother you if the 
iterator sacrifices a tiny bit of performance in exchange for a reliable order, 
and when you really need piecemeal initialisation, you could take a FSA-Variant 
that skips initialisation of elements.
Of course, that wouldn't be ideal, and there should be an "Unsafe" in the name 
of that type — but I don't think tuple-like delayed initialisation would help 
when solving real-world problems:
The "x.0 = 0; x.1 = 1" case is trivial and can be done with normal init, and 
when this isn't enough, you most likely loose all guarantees because you use a 
loop to fill that array*.

I really appreciate the effort you spend for digging into the low-level 
details, and hope that we end up with a draft that satisfies your use case.

- Tino

* There are actually cases where you want to compute the value of one element 
based on another one, but that might as well be an indicator that you are 
better off with a tuple, instead of using an array.

>> So would you say Dictionary shouldn't conform to Collection either?
>> Just because a type conforms to a protocol doesn't mean it can't add its own 
>> methods on top.
> 
> But the FSA interface and the Sequence/Collection interface would be very 
> similar, basically competing, leading to a schizophrenic interface. Since 
> another part of the overall FSA interface implements Collection, just use 
> that.
Yes, I can't argue against the claim that Collection sometimes feels a little 
bit odd :-( — but it is what it is, and maybe there will be improvements in the 
future that could take into account the experience with FSA.

>> Swift has one-dimensional arrays, and they support Collection... this may 
>> sound like nitpicking that only works because there is no explicit 
>> "fixed-size" in you statement, but feel free to prove me wrong for FSAs.
> 
> Yes, I meant FSAs, not both them and Array; it’s long-winded to keep adding 
> the “fixed-size” part.
So we do agree that there is no fundamental reason that stops FSAs from being 
collections? ;-)

>> Anyway, withUnsafe(Mutable)Flattening would be available as a standard 
>> global function for your Collection needs. It just isn’t built into the 
>> array types.
>> So people should get used to use an "unsafe" method for basic tasks like 
>> iteration?
> 
> withUnsafeFlattening is not the main FSA iteration task; it’s still the 
> for-loop. If you don’t care how traversal occurs, there’s no problem. Since 
> FSAs are built-ins instead of library types, I want the compiler to have the 
> freedom to determine its iteration method. If you care about a particular 
> traversal path, then implement the looping manually; you shouldn’t be hoping 
> that whatever order I’m convince to canonize happens to match your desired 
> order (or use withUnsafeFlattening if you want storage order). If you 
> manually loop not for the path order but to know the index, there’s the 
> “#indexOf” expression as the equivalent to Sequence.enumerated().
> 
> But wait, wouldn’t storage order be the best order? Maybe, leaning towards 
> yes, but there’s no reason to insist on it in case we’re wrong.
> 
> I’m not starting with Collection and trying to make FSAs fit, but starting 
> from the other direction, and seeing how compatible the interfaces are.

> (1) “Array” here is a named type (class/struct/enum), so you violated DI in 
> your initializer
> (2) “Array” is a compound type although it looks like a named type. That’s 
> confusing. (DI is satisfied as long as the last element is initialized before 
> it, or the object as a whole, is read.)
> [(3) “Array” is a type-alias to a more punctuator-soup-looking compound type. 
> That’s legal, but still a little confusing.]
I think FSAs should as much as possible behave like todays Array, so (1) is my 
choice.

 [ah, I think I got that point: It's not about leaving parts uninitialised 
 and taking care of them later, but the ability to use literals 

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Stephen Canon via swift-evolution]

> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> It’s important to remember that computers are mathematical machines, and some 
> functions which are implemented in hardware on essentially every platform 
> (like sin/cos/etc) are definitely best implemented as compiler intrinsics.

sin/cos/etc are implemented in software, not hardware. x86 does have the 
FSIN/FCOS instructions, but (almost) no one actually uses them to implement the 
sin( ) and cos( ) functions; they are a legacy curiosity, both too slow and too 
inaccurate for serious use today. There are no analogous instructions on ARM or 
PPC.

– Steve___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Stephen Canon via swift-evolution]

> On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution 
>  wrote:
> 
> I am of course not talking about a syntax sugar to call a sin or cos 
> function, but rather to manipulate other objects such as N-dimensional 
> matrices, defining maths functions that can take such matrices as argument 
> e.g. sin(A) with A as matrix produces a matrix of the same size where all 
> elements are the sinus values of the elements of A (sorry but things like 
> this calling map() with 'sin' looks quite ugly for scientists).


You’re on very shaky ground here. It is not at all obvious that sin(A) should 
be the “elementwise” sine that you suggest, and not the matrix sine (defined by 
plugging A into the power series for sine, which is globally convergent). 
Depending on what branch of science/math you come from, one of these is 
“obviously” the right answer, but I assure you that it’s very much not obvious.

Yes, we want libraries to build this sort of thing to exist.

No, it’s not clear what the “right” way to expose some of these operations in 
the language/library are.

It is better to be verbose but correct than to be terse and cause bugs.

– Steve___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Gwendal Roué via swift-evolution]

> Le 3 août 2017 à 02:09, Jordan Rose via swift-evolution 
>  a écrit :
> 
> P.S. There's a reason why Decodable uses an initializer instead of a 
> factory-like method on the type but I can't remember what it is right now. I 
> think it's something to do with having the right result type, which would 
> have to be either 'Any' or an associated type if it wasn't just 'Self'. (And 
> if it is 'Self' then it has all the same problems as an initializer and would 
> require extra syntax.) Itai would know for sure.

For anyone interested, factory methods *can* retroactivaly be added to existing 
classes. This is how the SQLite library GRDB.swift is able to decode classes 
hierarchies like NSString, NSNumber, NSDecimalNumber, etc. from SQLite values:

The protocol for types that can instantiate from SQLite values has a factory 
method:

public protocol DatabaseValueConvertible {
/// Returns a value initialized from *dbValue*, if possible.
static func fromDatabaseValue(_ dbValue: DatabaseValue) -> Self?
}

Having Foundation classes implement it uses various techniques:

1. "Casting" (Data to NSData, or NSDate to Date, depending on which type 
provides the root conformance)

// Workaround Swift inconvenience around factory methods of non-final 
classes
func cast(_ value: T) -> U? {
return value as? U
}

extension NSData : DatabaseValueConvertible {
public static func fromDatabaseValue(_ dbValue: DatabaseValue) -> Self? 
{
// Use Data conformance
guard let data = Data.fromDatabaseValue(dbValue) else {
return nil
}
return cast(data)
}
}

// Derives Date conformance from NSDate, for example
extension ReferenceConvertible where Self: DatabaseValueConvertible, 
Self.ReferenceType: DatabaseValueConvertible {
public static func fromDatabaseValue(_ dbValue: DatabaseValue) -> Self? 
{
return ReferenceType.fromDatabaseValue(dbValue).flatMap { cast($0) }
}
}


2. Using magic Foundation initializers (magic because the code below compiles 
even if those are not *required* initializers). Works for NSNumber, 
NSDecimalNumber, NSString:

extension NSNumber : DatabaseValueConvertible {
public static func fromDatabaseValue(_ dbValue: DatabaseValue) -> Self? 
{
switch dbValue.storage {
case .int64(let int64):
return self.init(value: int64)
case .double(let double):
return self.init(value: double)
default:
return nil
}
}
}

extension NSString : DatabaseValueConvertible {
public static func fromDatabaseValue(_ dbValue: DatabaseValue) -> Self? 
{
// Use String conformance
guard let string = String.fromDatabaseValue(dbValue) else {
return nil
}
return self.init(string: string)
}
}

The magic about Foundation initializers above makes me doubt that this 
technique is general enough for Decodable to profit from it, though. Yes it 
runs on Linux, so I'm not even sure if objc runtime is required or not. I'm 
clueless ???

Gwendal Roué

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Tino Heth via swift-evolution]

> Well that there is a rather defeatist attitude. If you are correct that 
> Apple-funded development is the only way to get core libraries built (and 
> maintained), and Apple has expressed they have no intention of doing so, then 
> we are all pretty much fd. 
I don't think Apple-funded development is the only way — it's just that the 
alternative takes much more time.
But ihmo the funding don't has to be large:
I wonder what would happen if Ted picked a random Swift developer, and gave him 
the maintainer credentials for an empty Result-repo on the official github 
page of Swift...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Elviro Rocca via swift-evolution]

Wrapper structs FTW. I think it's a lovely pattern that's super Swifty and 
really should be advertised more for solving these kinds of problems. 
Language-level features could also be useful for making that more usable, and 
the discussion about "strong" typealiases seems oriented in that direction.


Elviro


> Il giorno 03 ago 2017, alle ore 08:35, David Hart via swift-evolution 
> > ha scritto:
> 
> 
>> On 3 Aug 2017, at 08:00, Slava Pestov > > wrote:
>> 
>> 
>> 
>>> On Aug 2, 2017, at 10:48 PM, David Hart >> > wrote:
>>> 
>>> Somewhat related: I have a similar problem in a project where I need two 
>>> different Codable conformances for a type: one for coding/decoding from/to 
>>> JSON, and another one for coding/decoding from/to a database row. The keys 
>>> and formatting are not identical. The only solution around that for now is 
>>> separate types, which can be sub-optimal from a performance point of view.
>> Actually if the wrapper types are structs with a single field, their use 
>> should not introduce any additional overhead at runtime.
> 
> I ❤️ Swift
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>> Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Tino Heth via swift-evolution]

> You're welcome to join me in my endeavor to create a math library. I'd bet 
> Karoly feels the same way about his project.
See, exactly this is the big problem we are facing here — probably not in your 
specific case, but in general:
It's not very appealing for most people to contribute to a small library that's 
rarely known, instead of starting their own project to collect github stars...

- Tino

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

[Tino Heth via swift-evolution]

> The other point I'd make here is that I definitely think the core team is 
> right about encouraging any "entire API spec" for a math library to be based 
> on implementation experience from actually writing a math library that has 
> seen good adoption. Essentially, what they're saying is that any proposed 
> design here should have already proved itself in the field.
The things that are imho the most important to have don't need to be designed 
anymore — we only need to agree on a specific implementation.
A quick search for "Result Swift" on github yields 80 projects. I haven't 
looked at all of those, but I would be very surprised if the majority isn't 
more or less identical:
Names might be not all exactly the same, and some features won't exist 
everywhere… but I don't think it is a good idea to wait another two years to 
see if one of the implementations won the competition.
And even if one solution emerges to be the most popular: I bet it won't be 
because its quality, but some sort of marketing instead.

> I assume that you are well aware of Conway's law, which afaict has good 
> evidence to back it up; with that in mind, the end product that emerges from 
> a draft spec and an empty open-source repo is unlikely to be satisfactory, 
> let alone optimal.

That might be true for complicated stuff — but it took me some time to come up 
with examples for this category…

But there are at least three(!) implementations of quaternions in Apple 
libraries, and for this stupid reason, you can't directly take the data from 
the iPhones sensors and animate an object in scene kit with it. Is this 
satisfactory?

Imho it's not important for those missing "standard" libraries to have state of 
the art implementations for all established algorithms; it's much more valuable 
to agree on basics that are adopted by other libraries:
- I don't expect that Swift's dictionaries are optimal, but that isn't nearly 
as important as the fact that they are compatible with NSDictionary — or just 
imagine each library had it's own implementation of Array; it would be 
terrible, and a giant blocker for the adoption of Swift.
- A standard library for directed graphs doesn't need to have a version of A* 
or Dijkstras algorithm — it would already be a big step forward to declare the 
basic data structure, so that my variant of A* is compatible with someone 
else's graph visualisation toolkit.

- Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Inconsistencies related to prepositions

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Brent had a draft proposal to revise the names of collection methods to 
>> improve the situation here. There is room for improvement.
> 
> It didn't change `remove(at:)`, though. (Well, it might have affected its 
> return value or something, I don't remember.) It mostly addressed the 
> `dropLast()`, `prefix(_:)` etc. calls.
> 
> To respond to the original post:
> 
> Some of the APIs you cite are not very well named, but I think your diagnosis 
> is incorrect and so your prescription isn't going to help.
> 
>> The reason for this is, whenever a preposition is used in English, it almost 
>> always takes a dyadic form, relating a subject to the preposition's object. 
>> The two most common dyadic formats are:
>> 
>>  [ ]
>>  [ ] crossed the street. 
>> 
>> [ < object of preposition>] 
>> [ ],  can hear you scream.
>> [ ] are .
>> 
>> Now, in Objective C through Swift 1 and 2, prepositions' dyadic nature were 
>> generally respected in method signatures. However, Swift 3's migration of 
>> the preposition inside the parentheses also seems to have been accompanied 
>> by the stripping away of either the subject, the prepositional object, or 
>> both—according to no discernible pattern. For example: 
>> 
>> (1) CloudKit:
>> 
>> old: myCKDatabase.fetchRecordWithID(recordID)
>> new: myCKDatabase.fetch(withRecordID: recordID)
>> (subject "Record" got removed)
>> 
>> (2) String:
>> 
>> old: myString.capitalizedStringWithLocale(_: myLocale)
>> new: myString.capitalized(with: myLocale)
>> (subject "String" and prep. object "Locale" both got removed)
>> 
>> (3) Dictionary:
>> 
>> old: myDict.removeAtIndex(myIndex)
>> new: myDict.remove(at: myIndex)
>> (subject "element" already missing from both; prep. object "Index" got 
>> removed)
> 
> The thing is, the subjects and prepositional objects *are* present in all of 
> these—they are the parameters and targets of the calls. 
> 
> In your own example, you say "In space, no one can hear you scream", not "In 
> location space, group-of-people no one can hear you scream". So why is it a 
> problem that we say "myString, capitalized with myLocale" instead of 
> "myString, string capitalized with locale myLocale"? These are redundancies 
> that we would never tolerate in natural language; I don't see why you think 
> code should be different.
> 
>> (4) Date:
>> 
>> old: myDate.timeIntervalSinceDate(myDate)
>> new: myDate.timeIntervalSince(date: myDate)
>> (subject "timeInterval" and object "Date" both still present; but oddly, 
>> preposition "since" got left outside of the parentheses)
> 
> This is actually inaccurate—the parameter to `timeIntervalSince(_:)` is 
> unlabeled, so it's:
> 
>   new: myDate.timeIntervalSince(myDate)
> 
>> (5) Array:
>> 
>>  old: myArray.forEach({ thing in code})
>> new: myArray.forEach() { thing in //code }
>> (preposition “for” is outside of the parentheses)
> 
> Yes, because the preposition does not apply to the parameter—it applies to 
> the operation as a whole. I'll have more to say on this in a moment.
> 
>> The inconsistency between the examples is shown in the bold text of each 
>> example, but lets go over why this matters. It matters because any language 
>> is easier to learn the more consistently it sticks to its own rules.
> 
> 
> This is true, but you aren't just proposing sticking more closely to our 
> existing standards—you're proposing *changing* our standards. And I don't 
> think the changes you propose are an improvement. In fact, I'd say each of 
> these examples is worse:
> 
>> (1) myCKDatabase.fetchRecord(withRecordID:)
> 
> "Fetch record with record ID"? I mean, you could at least remove the `Record` 
> before `ID`. What other ID do you suppose it would be?
> 
> I *can* see the case for going back to `fetchRecord` instead of just `fetch`, 
> though. On the other hand, I do think that, if you know it's a database, the 
> most obvious thing for `fetch` to be fetching is a record from that database. 
> It's not a dog—it won't be fetching a stick.
> 
>> (2) myString.stringCapitalized(withLocale:)
> 
> Let's translate this to an actual use site, which is what we care about.
> 
>   func tableView(_: UITableView, titleForHeaderInSection section: Int) -> 
> String? {
>   return sections[section].title.stringCapitalized(withLocale: 
> .current)
>   }
> 
> What is `string` contributing here? We already know it's a "title", which 
> sounds a lot like a string. If you asked for a "capitalized" string, what 
> else would you get back if not another string?
> 
> The locale parameter is a little more tricky. You're right that `(with: 
> .current)` is vague, but I can imagine plenty of call sites where `with` 
> wouldn't be:
> 
>   

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[David Hart via swift-evolution]

> On 3 Aug 2017, at 08:00, Slava Pestov  wrote:
> 
> 
>> On Aug 2, 2017, at 10:48 PM, David Hart > > wrote:
>> 
>> Somewhat related: I have a similar problem in a project where I need two 
>> different Codable conformances for a type: one for coding/decoding from/to 
>> JSON, and another one for coding/decoding from/to a database row. The keys 
>> and formatting are not identical. The only solution around that for now is 
>> separate types, which can be sub-optimal from a performance point of view.
> 
> Actually if the wrapper types are structs with a single field, their use 
> should not introduce any additional overhead at runtime.

I ❤️ Swift

> Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 3 Aug 2017, at 01:09, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 'required' initializers are like methods: they may require dynamic dispatch. 
> That means that they get an entry in the class's dynamic dispatch table, 
> commonly known as its vtable. Unlike Objective-C method tables, vtables 
> aren't set up to have entries arbitrarily added at run time.
> 
> (Aside: This is one of the reasons why non-@objc methods in Swift extensions 
> can't be overridden; if we ever lift that restriction, it'll be by using a 
> separate table and a form of dispatch similar to objc_msgSend. I sent a 
> proposal to swift-evolution about this last year but there wasn't much 
> interest.)

If I missed replying to that originally I also missed the chance to say that it 
would be a lovely idea and dynamic dispatch in some cases is just what the 
doctor ordered (runtime editable method tables).
This is especially especially important with extensions for classes and default 
methods (and the current rules for overriding methods in the implementing 
class), please resubmit the proposal :).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution