Re: [swift-users] Dimensional analysis

[Howard Lovatt via swift-users]

Another feature I would like would be a dimensions wrapper for an array. So
that I can mark all values in the array as having the same units, rather
than mark each individual element as having a particular unit.

It is conceivable that wrapping each element, both performance and memory
wise, is OK depending on implementation. However my experience with
Mathematica's Quantity is that wrapping each element is a significant
overhead. Therefore I would like a dimensioned array.

As an aside. It might be a lot easier to write an array wrapper when we get
Conditional Conformance To Protocols with the improved generics slated for
Swift 4.1. Therefore it might be worth waiting until 4.1. before attempting
a dimensioned array.

  -- Howard.

On 1 December 2016 at 01:17, Maury Markowitz via swift-users <
swift-users@swift.org> wrote:

> Let me add my support for this as well. I am currently using a bridge
> version of:
>
> https://github.com/unixpickle/Expressions
>
> And it works quite well. But I think a pure Swift implementation,
> especially with dimensional analysis, would be useful to a great number of
> people.
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Dealing with loss of observers on protocol properties with default implementations

[Tino Heth via swift-users]

> I find this to be an ugly solution. Particularly so since non-objc protocols 
> don't support optional members. Compare this to using a base class:

If inheritance works well, I wouldn't insist on protocols just for the sake of 
it.
This wont help with structs, but your example uses a class… and if you can't 
use inheritance for other reasons, you could try composition instead.___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Dealing with loss of observers on protocol properties with default implementations

[Neil via swift-users]

Hi folks, 

I'm curious to know how others have handled the loss of property observers when 
a protocol property has a default implementation. 

For example, consider the following simple protocol declaration:

protocol Widget : class {
associatedtype IdentifierType
var identifier: IdentifierType { get set }
}

extension Widget {
var identifier: IdentifierType {
get {
return ... 
}
set {
... 
}
}
}

A class conforming to the Widget protocol cannot leverage property observers on 
the identifier property without overriding the default implementation:

class WidgetFactory: Widget {
typealias IdentifierType = Int

// Overrides the default implementation
var identifier: Int {
didSet {
  // ...
}
}
}

This is problematic when the default implementation goes beyond merely 
getting/setting a backing variable. The only solution I've come up with is to 
mandate a willSet/didSet function pair for each protocol property:

protocol Widget : class {
associatedtype IdentifierType
var identifier: IdentifierType { get set }

func willSetIdentifier(_ newValue: IdentifierType)
func didSetIdentifier(_ newValue: IdentifierType)
}

extension Widget {
var identifier: IdentifierType {
get {
return ... 
}
set {
... 
}
willSet {
willSetIdentifier(newValue)
}
didSet {
didSetIdentifier(identifier)
}
}
}

I find this to be an ugly solution. Particularly so since non-objc protocols 
don't support optional members. Compare this to using a base class:

protocol Widget : class {
associatedtype IdentifierType
var identifier: IdentifierType { get set }
}

class BaseWidget : Widget {
typealias IdentifierType = Int

var identifier: Int {
get {
return ...
}
set {
...
}
}
}

class WidgetFactory : BaseWidget {
// This doesn't override the getter/setter implementation in the base class
override var identifier: Int {
willSet {
...
}
}
}

Has anyone else faced this situation? If so, what was your solution?

-- Neil








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

[swift-users] Atomics and Memory Fences in Swift

[Anders Ha via swift-users]

Hi guys

I have recently started adopting lock-free atomics with memory fences, but it 
seems Swift at this moment does not have any native instruments.

Then I read a thread in the Apple Developer Forum 
(https://forums.developer.apple.com/thread/49334 
), which an Apple staff 
claimed that all imported atomic operations are "not guaranteed to be atomic". 
But for my tests with all optimizations enabled (-Owholemodule and -O), the 
OSAtomic primitives and stdatomic fences do not seem going wild.

Is these `atomic_*` and `OSAtomic*` primitives really unsafe in Swift as 
claimed? It doesn't seem like the Swift compiler would reorder memory accesses 
around a C function call that it wouldn't be able to see through.

P.S. Is any of these primitives available on Linux? It seems the glibc 
modulemap does not export an `stdatomic` submodule at all.

Best Regards,
Anders

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

[swift-users] Capture values by Closures in different background threads.

[Седых Александр via swift-users]

Assume we have this code:
 
Immediately two Timer's closures captured two copy of initial values of 
instance Test, with internal num values is 0.
 
//: Playground - noun: a place where people can play
 
import UIKit
 
var str =  "Hello, playground"
 
struct Test {
     var num =  0
     mutating func newNum(new:  Int ) {
         num = new
    }
}
 
var test =  Test ()
 
Timer . scheduledTimer (withTimeInterval:  1.0 , repeats:  false ) { (timer)  in
     print ( "tick" )
     test . newNum (new:  8 )
}
 
Timer . scheduledTimer (withTimeInterval:  2.0 , repeats:  false ) { (timer)  in
     print ( "tack, test.num =  \ ( test . num )" )
}
 
 
CFRunLoopRun ()



We have next log:
tick
tack, test.num = 8
 
Why Timer's two closure return to us value 8 and not 0?


-- 
Седых Александр___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users