Re: [swift-users] CustomStringConvertible?
Ah, yes. It is possible to ‘store’ it as a fixed string.
But I would still expect the compiler to treat it as if it were a computed
property.
Given that this is a protocol and a protocol cannot define stored properties.
(yet anyway)
OTOH, what do I know about compilers… lol!
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> On 08 Sep 2017, at 20:26, Michael Rogers wrote:
>
> Thanks for your reply, Rien. I just tried this again, and now it seems that
> either is acceptable. Seems a little weird, but I guess I’d rather have more
> flexibility than less.
>
> protocol Powerable {
> var isOn:Bool { get set } // Must have get and set
> var usesDC:Bool { get } // Must have get, may have set
> func turnOn()
> func turnOff()
> }
>
> class GPS : Powerable, CustomStringConvertible {
> // Either of these work
> //var description: String {
> //return "I am a GPS"
> //}
> var description:String = "I am a GPS"
> var isOn: Bool = false
> var usesDC: Bool = false
>
> // does the obvious
> func turnOn(){
> isOn = true
> }
>
> // does the obvious
> func turnOff() {
> isOn = false
> }
> }
>
> print(GPS()) // output: I am a GPS (both cases)
>
> Michael
>
>> On Sep 8, 2017, at 1:21 PM, Rien wrote:
>>
>> It cannot be ‘stored’ I would think.
>> I always compute my implementations.
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
>>
>>
>>
>>
>>
>>
>>
>>> On 08 Sep 2017, at 19:47, Michael Rogers via swift-users
>>> wrote:
>>>
>>> Quick question (for my own edification, as well as to demonstrate to my
>>> students the power of this mail list 😉), is CustomStringConvertible a
>>> stored property or a computed property? The docs say the latter, but when
>>> using Xcode’s fabulous FIX button, it seems to imply it’s a stored
>>> property.
>>>
>>> Michael
>>> ___
>>> 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] CustomStringConvertible?
It cannot be ‘stored’ I would think. I always compute my implementations. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift > On 08 Sep 2017, at 19:47, Michael Rogers via swift-users > wrote: > > Quick question (for my own edification, as well as to demonstrate to my > students the power of this mail list 😉), is CustomStringConvertible a stored > property or a computed property? The docs say the latter, but when using > Xcode’s fabulous FIX button, it seems to imply it’s a stored property. > > Michael > ___ > 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
[swift-users] Very large NSNumber values
I was working with very large NSNumber values and noticed some odd behaviour when converting these values to integers. An NSNumber with the value +1e+40 will when converted to Ints produce integers wit the value zero for Int8, UInt8, Int16, UInt16, Int32 and UInt32. But for Int64 it will produce Int64.min And for UInt64 it will produce UInt64.max It would seem to me that it would be better if the behaviour were consistent for all conversions. Worthy of a bug report? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] JSON keys survey
> On 23 Jun 2017, at 18:42, Tony Parker via swift-users > wrote: > > Hi all, > > This has come up a few times in recent threads, and I wanted to gather some > additional info on your real world use cases. Just reply to me, and any input > is appreciated: > > 1. Does your JSON use snake_case_keys or CamelCase or other? Mostly CamelCase but sometimes Capitalised Spaced Out Keys > 2. Is the key type consistent throughout the JSON? Depends on usage > 3. If JSONEncoder/Decoder converted these, would you have any other need to > specify custom keys? Unsure, probably. > > Thanks, > - Tony > > ___ > 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] Should I be using more catchless do blocks?
Yes. But: Only if it makes the code better. I think that “understandability engineering” is just as important as “software engineering”. Maybe more so. After all, code that we understand has a better chance of working correctly than code that follows all paradigms but once the developer is gone nobody is able to maintain. I.e. worry less about idiomatic programming and write more understandable code. Swift is getting - well maybe it’s past already - the point where an experienced programmer can write code that no newbie has even a chance of understanding. If code blocks help in breaking this trend, go for it. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift > On 19 Jun 2017, at 04:07, Michael Savich via swift-users > wrote: > > So, something I did not know until recently is that do blocks in Swift are > for more than just error handling, they can also be used to tighten scope. > > I'm wondering, why not use a ton of do blocks? Like, if I have a > ViewController lifecycle method like viewDidLoad, I could segment it into out > a do block for creating subviews, a do block for loading data into them, and > a do block for adding them to the view itself. This seems like it would > enforce grouping code tightly together. > > Yes I could adopt a functional style of programming, but that has its > downsides too, namely reading any functional code involves trawling through a > long sequence of function calls. What I'm saying is, do blocks seem like a > way to get many of the benefits of functional programming while maintaining > the readability of imperative code. (Sorry functional programmers, I promise > I love Haskell too!) > > So I guess what I'm saying is… somebody talk me down from this ledge. Is > there a reason I shouldn't refactor my projects to be full of do blocks? And > can this usage of do really be considered idiomatic Swift? Or will most > people reading my code be left wondering where all the try and catch > statements are? > > Sent from my iPad > ___ > 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] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4
Dang, hit send too soon. Sorry.
This does not address your question, so please ignore… (foot in mouth)!
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> On 18 Jun 2017, at 09:19, Rien wrote:
>
> Are you looking for a general purpose JSON interpreter / API ?
>
> There are many of them around, and in fact I do have my own:
> https://github.com/Balancingrock/VJson
>
> With VJson I would write:
>
> let json = VJson.parse(… your json object…)
>
> and then access the metadata as:
>
> let buyCount = (json | ”metadata” | ”buy_count”)?.intValue
>
> or:
>
> var buyCount: Int &= json | “metadata” | “buy_count”
>
> To loop over the content of metadata:
>
> for item in (json | “metadata”) ?? [ ] {
> print (item.nameValue)
> switch item.type {
> case .object: …
> case .number: …
> case .string: …
> etc...
> }
> }
>
> Obviously I am plugging my own code here, but there are many others around, I
> understand that SwiftyJSON is quite popular but I have not used that myself.
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
>
>
>
>
>
>
>
>> On 18 Jun 2017, at 04:07, Chris Anderson via swift-users
>> wrote:
>>
>> Say I have a JSON object such as:
>>
>> {
>>"id": "4yq6txdpfadhbaqnwp3",
>>"email": "john@example.com",
>>"name":"John Doe",
>>"metadata": {
>> "link_id": "linked-id",
>> "buy_count": 4
>>}
>> }
>>
>> And with a struct of:
>>
>> struct User: Codable {
>> var id: String
>> var email: String
>> var name: String
>> }
>>
>> How can I decode the `metadata` field into a Dictionary?
>>
>> I’ve tried doing things such as, in my struct,
>>
>> var metadata: Dictionary
>>
>> or
>>
>> var metadata: [String: Any]
>>
>> But I get the error
>>
>> MyPlayground.playground:3:7: note: cannot automatically synthesize
>> 'Encodable' because '<>' does not conform to 'Encodable'
>> var metadata: Dictionary
>>
>> A meta or metadata field on many APIs (such as www.stripe.com) can contain
>> whatever you want, and I still want to be able to process it on the Swift
>> end. How can I store that meta data field into a Dictionary that I can parse
>> apart manually after?
>>
>> Thanks!
>>
>> Chris Anderson
>>
>>
>>
>>
>>
>> ___
>> 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] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4
Are you looking for a general purpose JSON interpreter / API ?
There are many of them around, and in fact I do have my own:
https://github.com/Balancingrock/VJson
With VJson I would write:
let json = VJson.parse(… your json object…)
and then access the metadata as:
let buyCount = (json | ”metadata” | ”buy_count”)?.intValue
or:
var buyCount: Int &= json | “metadata” | “buy_count”
To loop over the content of metadata:
for item in (json | “metadata”) ?? [ ] {
print (item.nameValue)
switch item.type {
case .object: …
case .number: …
case .string: …
etc...
}
}
Obviously I am plugging my own code here, but there are many others around, I
understand that SwiftyJSON is quite popular but I have not used that myself.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> On 18 Jun 2017, at 04:07, Chris Anderson via swift-users
> wrote:
>
> Say I have a JSON object such as:
>
> {
> "id": "4yq6txdpfadhbaqnwp3",
> "email": "john@example.com",
> "name":"John Doe",
> "metadata": {
> "link_id": "linked-id",
> "buy_count": 4
> }
> }
>
> And with a struct of:
>
> struct User: Codable {
> var id: String
> var email: String
> var name: String
> }
>
> How can I decode the `metadata` field into a Dictionary?
>
> I’ve tried doing things such as, in my struct,
>
> var metadata: Dictionary
>
> or
>
> var metadata: [String: Any]
>
> But I get the error
>
> MyPlayground.playground:3:7: note: cannot automatically synthesize
> 'Encodable' because '<>' does not conform to 'Encodable'
> var metadata: Dictionary
>
> A meta or metadata field on many APIs (such as www.stripe.com) can contain
> whatever you want, and I still want to be able to process it on the Swift
> end. How can I store that meta data field into a Dictionary that I can parse
> apart manually after?
>
> Thanks!
>
> Chris Anderson
>
>
>
>
>
> ___
> 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] Future(of: self.references)?
I will often use this rule: If a scope need to use ‘self’ at least once, then I
will always use ‘self’ in that scope.
Otherwise I won’t use ’self’ at all.
There are always exceptions though, first and foremost: if the usage of ‘self’
hinders understandability of the code (interferes with self documentation),
then don’t use it.
Also the usage of ‘self’ in a guard statement does not count.
Mostly though I will try and avoid the necessity for using ’self’ at all. It
often is an indication that names are not correct or not optimal.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
> On 23 May 2017, at 11:30, Tino Heth via swift-users
> wrote:
>
> Well, sometimes it might be important that you are dealing with an instance
> variable, and in other cases, it's just clutter:
> struct Triangle {
> var a: Float
> var b: Float
> var c: Float
>
> var isSquare: Bool {
> return self.a * self.a + self.b * self.b == self.c * self.c
> }
>
> var isStillSquare: Bool {
> return a * a + b * b == c * c
> }
> }
> Imho the second variant is clearly better than the first, and it would be bad
> to enforce self.
>
> My personal rule of thumb for this is: Use the self prefix for things that
> should change self, skip it for read-only access — but the exact "rules" are
> quite arcane, and I think the compiler shouldn't have to deal with
> complicated rules that still would fail to make everyone happy.
> So, I think the current approach is the best we can do.
> ___
> 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
[swift-users] Generating html code, best practise?
I want to generate some HTML code with Swift. Of course there are many way to do this, but I am not looking to do an "in-dept all options open” approach. Just some ‘get the html out quickly” type of thing. So I wonder, how do _you_ do this? Simply using Strings is one option, but cumbersome and without any ‘html-type-safety’ Using some general purpose function (e.g. func tagged(tag: String, content: String) -> String) helps a little, but not very much. Enums are another possibility. Or var’s in a struct/class that wrap the html element etc. Many possibilities. Any suggestion is welcome, suggestions as wel as experiences. Of course if there is a solution out there, I’d like to know as well. (I didn’t find any though) Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - A server for websites build in Swift ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Making Error sub-enums Equatable
I’d love to know if there is a better way, but a ‘switch’ or 'if case' is the
only way I know.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
> On 08 May 2017, at 11:01, Rick Mann via swift-users
> wrote:
>
> Seriously, I've been googling this for a half-hour, and I can't find an
> answer (everything that comes up is for ErrorType, absolutely nothing for
> Error).
>
> I have an enum:
>
> enum MyErrors : Error
> {
>case one(String)
>case two
>case three(String)
> }
>
> let a: MyErrors = .one("foo")
> let b = .two
> let c = .towo
>
> I want to compare them with ==, and I don't care about the associated types.
> I can't for the life of me figure out how without an exhaustive switch
> statement in a == definition. Is that the only way?
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> ___
> 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] weak self
Thanks Guillaume,
Interesting: this is a kind-of symmetry break between optionals and weak
references.
I.e. most (inexperienced?) programmers will see a strong similarity between
weak references and optionals.
And for a lot of use cases they do indeed behave similar.
But for weak references I think the guideline should be: Never ‘force-unwrap’
it.
Maybe this should be mentioned in the swift guide?
Maybe even include a warning in the compiler for this?
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
> On 01 May 2017, at 23:26, Guillaume Lessard
> wrote:
>
> Hi Rien,
>
>> On May 1, 2017, at 08:46, Rien via swift-users wrote:
>>
>> In my code I use a lot of queues. And (very often) I will use [weak self] to
>> prevent doing things when ‘self’ is no longer available.
>>
>> Now I am wondering: how does the compiler know that [weak self] is
>> referenced?
>
> The object never knows whether a weak reference to it is being used; in order
> to be safe you must bind the reference — then you get a strong reference out
> of it, and that guarantees the object stays alive as long as the strong
> reference is in scope.
>
>
>> I am assuming it keeps a reverse reference from self to the [weak self] in
>> order to ‘nil’ the [weak self] when self is nilled.
>
> It does not.
>
> From the perspective of the runtime, weak references are a different type
> than normal/strong references; what’s important to know here is that getting
> a strong reference from a weak one is thread-safe. It’s interesting to know
> that weak references to “dead” objects are nilled out on use, lazily. When a
> WeakReference is used, the object’s strong reference count is checked, and if
> that is zero then the WeakReference is nilled out.
>
> You could read Mike Ash’s description at
> <https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html>.
> That describes Swift 3 weak references quite well. There’s a newer
> implementation of reference counting for Swift 4, but the outwardly-visible
> behaviour is the same.
>
>
>> But when a job is executing it has no control over the exclusive rights to
>> [weak self].
>>
>> I.e. [weak self] may be nilled by an outside event in the middle of say:
>>
>> if self != nil { return self!.myparam }
>>
>> The if finding [weak self] non nil, but the return finding [weak self] as nil
>>
>> Is that correct? i.e. should we never use the above if construct but always:
>
> There is potential for a race on `self`, as the strong reference count could
> go to zero between the two uses of the weak reference.
>
> The proper way is
>
> if let myref = self { return myref.myparam }
>
> (or the equivalent guard.)
> That’s safe.
>
> Cheers,
> Guillaume Lessard
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] weak self
> On 01 May 2017, at 17:42, Dennis Weissmann wrote:
>
>>
>> On May 1, 2017, at 5:32 PM, Rien wrote:
>>
>>>
>>> On 01 May 2017, at 16:59, Dennis Weissmann
>>> wrote:
>>>
>>>>
>>>> On May 1, 2017, at 4:46 PM, Rien via swift-users
>>>> wrote:
>>>>
>>>> In my code I use a lot of queues. And (very often) I will use [weak self]
>>>> to prevent doing things when ‘self’ is no longer available.
>>>>
>>>> Now I am wondering: how does the compiler know that [weak self] is
>>>> referenced?
>>>>
>>>> I am assuming it keeps a reverse reference from self to the [weak self] in
>>>> order to ‘nil’ the [weak self] when self is nilled.
>>>>
>>>> But when a job is executing it has no control over the exclusive rights to
>>>> [weak self].
>>>>
>>>> I.e. [weak self] may be nilled by an outside event in the middle of say:
>>>>
>>>>if self != nil { return self!.myparam }
>>>>
>>>> The if finding [weak self] non nil, but the return finding [weak self] as
>>>> nil
>>>>
>>>> Is that correct? i.e. should we never use the above if construct but
>>>> always:
>>>>
>>>>return self?.myparam ?? 42
>>>>
>>>
>>> Yes, as you said, you never know when self will be nilled out, that's why
>>> you need to create a (temporary) strong reference to it, work on it, and
>>> when the block returns, your strong reference is released and self either
>>> goes away immediately (incase it was released elsewhere after the local
>>> binding to a strong variable and no other objects had a strong reference to
>>> it) or it will stay as long as no other object holds a strong reference to
>>> it.
>>>
>>> When the closure is more involved than a view lines, I often do a guard let
>>> `self` = self else { return } to conveniently work with a strong self
>>> inside the rest of the closure.
>>
>> I was aware of that practise (use it myself) but I was not sure if it would
>> always work.
>> I.e. I have not found it documented that
>> let strongSelf = self
>> will actually retain ‘self’ an not create a strong reference to an
>> intermediate reference to self.
>>
>> It makes sense though, otherwise there would be massive failures ‘out
>> there’. ;-)
>>
>
> Yes :) local variables (as others too) are strong by default. If you want
> them weak (you should very rarely need that though) you have to explicitly
> mark them weak.
>
>> will actually retain ‘self’ an not create a strong reference to an
>> intermediate reference to self.
>
> Isn't that the same? I might misunderstand you but they would both reference
> the same object, no? So in the end the retain message would be sent to the
> same object, wouldn't it?
Just to belabour this point unnecessarily :)
If you are familiar with the compiler innards, then this might be obvious.
However I am not, and I can imagine (crazy) scenario’s where an optional woud
be “unwrapped” by simply taking the reference to the self from the optional and
storing it in a new non-optional variable… :D … go figure… the mind works in
devious ways… lol.
Rien.
>
>> Thanks,
>> Rien.
>>
>>>
>>>> Regards,
>>>> Rien
>>>>
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Balancingrock
>>>> Project: http://swiftfire.nl - A server for websites build in Swift
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>>> - Dennis
>
> - Dennis
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] weak self
> On 01 May 2017, at 16:59, Dennis Weissmann wrote:
>
>>
>> On May 1, 2017, at 4:46 PM, Rien via swift-users
>> wrote:
>>
>> In my code I use a lot of queues. And (very often) I will use [weak self] to
>> prevent doing things when ‘self’ is no longer available.
>>
>> Now I am wondering: how does the compiler know that [weak self] is
>> referenced?
>>
>> I am assuming it keeps a reverse reference from self to the [weak self] in
>> order to ‘nil’ the [weak self] when self is nilled.
>>
>> But when a job is executing it has no control over the exclusive rights to
>> [weak self].
>>
>> I.e. [weak self] may be nilled by an outside event in the middle of say:
>>
>> if self != nil { return self!.myparam }
>>
>> The if finding [weak self] non nil, but the return finding [weak self] as nil
>>
>> Is that correct? i.e. should we never use the above if construct but always:
>>
>> return self?.myparam ?? 42
>>
>
> Yes, as you said, you never know when self will be nilled out, that's why you
> need to create a (temporary) strong reference to it, work on it, and when the
> block returns, your strong reference is released and self either goes away
> immediately (incase it was released elsewhere after the local binding to a
> strong variable and no other objects had a strong reference to it) or it will
> stay as long as no other object holds a strong reference to it.
>
> When the closure is more involved than a view lines, I often do a guard let
> `self` = self else { return } to conveniently work with a strong self inside
> the rest of the closure.
I was aware of that practise (use it myself) but I was not sure if it would
always work.
I.e. I have not found it documented that
let strongSelf = self
will actually retain ‘self’ an not create a strong reference to an intermediate
reference to self.
It makes sense though, otherwise there would be massive failures ‘out there’.
;-)
Thanks,
Rien.
>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - A server for websites build in Swift
>>
>>
>>
>>
>>
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>
> - Dennis
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] weak self
In my code I use a lot of queues. And (very often) I will use [weak self] to
prevent doing things when ‘self’ is no longer available.
Now I am wondering: how does the compiler know that [weak self] is referenced?
I am assuming it keeps a reverse reference from self to the [weak self] in
order to ‘nil’ the [weak self] when self is nilled.
But when a job is executing it has no control over the exclusive rights to
[weak self].
I.e. [weak self] may be nilled by an outside event in the middle of say:
if self != nil { return self!.myparam }
The if finding [weak self] non nil, but the return finding [weak self] as nil
Is that correct? i.e. should we never use the above if construct but always:
return self?.myparam ?? 42
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Why does withUnsafePointer(to:) require a var argument?
You will need to take full control over allocation and deallocation.
Here is a piece of code from my project SwifterSockets (on github, see the link
in my signature)
public func tipReceiverLoop(
socket: Int32,
bufferSize: Int,
duration: TimeInterval,
receiver: ReceiverProtocol?) {
...
// Allocate the data buffer
let buffer = UnsafeMutableRawPointer.allocate(bytes: bufferSize, alignedTo:
1)
//
===
// This loop stays active as long as the consumer wants more and no error
occured.
//
===
var cont = true
repeat {
...
//
// Wait until select signals incoming data activity
//
let selres = waitForSelect(socket: socket, timeout: timeout, forRead:
true, forWrite: false)
switch selres {
...
case .ready:
// =
// Call the recv
// =
let bytesRead = Darwin.recv(socket, buffer.assumingMemoryBound(to:
UInt8.self), bufferSize, 0)
switch bytesRead {
...
case 1 ... Int.max: // Callback for the received data
cont = receiver?.receiverData(UnsafeBufferPointer(start:
buffer.assumingMemoryBound(to: UInt8.self), count: bytesRead)) ?? true
...}
}
} while cont
// Deallocate the data buffer
buffer.deallocate(bytes: bufferSize, alignedTo: 1)
}
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
> On 28 Apr 2017, at 08:02, Rick Mann wrote:
>
> Yeah, okay. So: how do I do this in a way that is safe?
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>> On Apr 27, 2017, at 23:00, Rien wrote:
>>
>> To address your question:
>>
>> https://developer.apple.com/reference/foundation/data/1779823-withunsafemutablebytes
>>
>> "Warning
>> The byte pointer argument should not be stored and used outside of the
>> lifetime of the call to the closure."
>>
>> Which is exactly what you are doing, hence the code is unsafe (no pun
>> intended).
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - A server for websites build in Swift
>>
>>
>>
>>
>>
>>
>>> On 28 Apr 2017, at 01:38, Rick Mann wrote:
>>>
>>>
On Apr 27, 2017, at 01:48 , Alex Blewitt wrote:
>>> ...
>>>
The let constant may not even be stored in a single place; if it's known
to be constant it can be in-lined at the point of use and potentially
unpacked and dead code elimination throw away the unused members, for
example.
If you want to pass in a let constant into the pointer, you can create a
copy of it locally in a local variable and then use that instead. However
this will be in the local scope, so the pointer isn't valid after it
returns.
>>>
>>> Ah, so this brings up another issue, then. Many of the calls in the C
>>> library take a pointer to some memory and hang on to it, filling it in at a
>>> later point (they make network requests). I've been doing it like this, and
>>> it's been working, but I wonder if this is fragile:
>>>
>>> class
>>> MyClass
>>> {
>>> func
>>> execute()
>>> {
>>> self.dataBuffer = Data(count: kLGSImageDataSize)
>>> precondition(self.dataBuffer != nil, "Unable to allocate image buffer
>>> (\(kLGSImageDataSize) bytes)")
>>>
>>> var params = c_library_params_t()
>>> params.data_capacity = self.dataBuffer!.count
>>>
>>> self.dataBuffer?.withUnsafeMutableBytes
>>> { (inBuffer) -> Void in
>>> // This call returns immediately, but assumes
>>> // it can write to inBuffer later…
>>>
>>> self.request = c_library_call(¶ms, inBuffer)
>>> }
>>>
>>> if self.request == nil
>>> {
>>> // Error
>>> }
>>> }
>>>
>>> var dataBuffer: Data?
>>> }
>>>
>>>
>>> --
>>> Rick Mann
>>> rm...@latencyzero.com
>>>
>>>
>>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Why does withUnsafePointer(to:) require a var argument?
To address your question:
https://developer.apple.com/reference/foundation/data/1779823-withunsafemutablebytes
"Warning
The byte pointer argument should not be stored and used outside of the lifetime
of the call to the closure."
Which is exactly what you are doing, hence the code is unsafe (no pun intended).
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
> On 28 Apr 2017, at 01:38, Rick Mann wrote:
>
>
>> On Apr 27, 2017, at 01:48 , Alex Blewitt wrote:
>>
> ...
>
>> The let constant may not even be stored in a single place; if it's known to
>> be constant it can be in-lined at the point of use and potentially unpacked
>> and dead code elimination throw away the unused members, for example.
>>
>> If you want to pass in a let constant into the pointer, you can create a
>> copy of it locally in a local variable and then use that instead. However
>> this will be in the local scope, so the pointer isn't valid after it returns.
>
> Ah, so this brings up another issue, then. Many of the calls in the C library
> take a pointer to some memory and hang on to it, filling it in at a later
> point (they make network requests). I've been doing it like this, and it's
> been working, but I wonder if this is fragile:
>
> class
> MyClass
> {
>func
>execute()
>{
>self.dataBuffer = Data(count: kLGSImageDataSize)
>precondition(self.dataBuffer != nil, "Unable to allocate image buffer
> (\(kLGSImageDataSize) bytes)")
>
>var params = c_library_params_t()
>params.data_capacity = self.dataBuffer!.count
>
>self.dataBuffer?.withUnsafeMutableBytes
>{ (inBuffer) -> Void in
>// This call returns immediately, but assumes
>// it can write to inBuffer later…
>
>self.request = c_library_call(¶ms, inBuffer)
>}
>
>if self.request == nil
>{
>// Error
>}
>}
>
>var dataBuffer: Data?
> }
>
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Why does withUnsafePointer(to:) require a var argument?
> On 27 Apr 2017, at 09:54, Rick Mann wrote: > >> >> On Apr 26, 2017, at 23:37 , Rien via swift-users >> wrote: >> >> 1) When you obtain a pointer, it can no longer be ensured by the compiler >> that you won’t write to it. >> 2) A ‘let’ variable (constant) allows way more optimizations than a ‘var’. I >> would not be surprised if the majority of ‘let’ constants never see any >> memory allocation at all. > > In my case, it's a field in a struct that's allocated elsewhere, and most > certainly exists, and is passed as a parameter, so it's 'let'. I really want > to be able to say "I promise I won't write to this", which seems reasonable > if the language is willing to give me an unsafe pointer in the first place. IIRC this is the reason for the mutable and non-mutable version of the pointer. With the non-mutable pointer you cannot write to the pointee. (At least not without some additional code) But it is another step entirely to then allow a let assignment to be used as the pointee. I assume the Swift team decided to keep things simple and not allow let’s to be used as pointee’s. It could probably be done in theory, but I imagine that to be a nightmare case for compiler writers... Regards, Rien. > > How is the immutable version of withUnsafePointer different from the mutable > one? It passes the argument to the closure as a mutable pointer, which must > mean something different. > >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Balancingrock >> Project: http://swiftfire.nl - A server for websites build in Swift >> >> >> >> >> >> >>> On 27 Apr 2017, at 08:31, Florent Bruneau via swift-users >>> wrote: >>> >>> Hi Rick, >>> >>> My understanding on this is that withUnsafePointer() requires an inout >>> argument because it has to take a reference to the variable in order to be >>> able to derive its pointer. The languages requires inout arguments to be >>> vars, leading to withUnsafePointer() requiring the passed object to be a >>> var. >>> >>> There may be other subtleties I'm not aware of, though. >>> >>>> Le 27 avr. 2017 à 02:42, Rick Mann via swift-users >>>> a écrit : >>>> >>>> We have withUnsafePointer(to:) and withUnsafeMutablePointer(to:). Why does >>>> the first take an inout parameter? The function names imply that the first >>>> will not modify the pointer (which I take to mean its contents), and it >>>> makes it quite clunky to pass in constant things. >>>> >>>> -- >>>> Rick Mann >>>> rm...@latencyzero.com >>>> >>>> >>>> ___ >>>> swift-users mailing list >>>> swift-users@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-users >>> >>> -- >>> Florent Bruneau >>> >>> ___ >>> 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 > > > -- > Rick Mann > rm...@latencyzero.com ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Why does withUnsafePointer(to:) require a var argument?
1) When you obtain a pointer, it can no longer be ensured by the compiler that you won’t write to it. 2) A ‘let’ variable (constant) allows way more optimizations than a ‘var’. I would not be surprised if the majority of ‘let’ constants never see any memory allocation at all. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - A server for websites build in Swift > On 27 Apr 2017, at 08:31, Florent Bruneau via swift-users > wrote: > > Hi Rick, > > My understanding on this is that withUnsafePointer() requires an inout > argument because it has to take a reference to the variable in order to be > able to derive its pointer. The languages requires inout arguments to be > vars, leading to withUnsafePointer() requiring the passed object to be a var. > > There may be other subtleties I'm not aware of, though. > >> Le 27 avr. 2017 à 02:42, Rick Mann via swift-users a >> écrit : >> >> We have withUnsafePointer(to:) and withUnsafeMutablePointer(to:). Why does >> the first take an inout parameter? The function names imply that the first >> will not modify the pointer (which I take to mean its contents), and it >> makes it quite clunky to pass in constant things. >> >> -- >> Rick Mann >> rm...@latencyzero.com >> >> >> ___ >> swift-users mailing list >> swift-users@swift.org >> https://lists.swift.org/mailman/listinfo/swift-users > > -- > Florent Bruneau > > ___ > 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] edit array
Agree, though the function should probably be named something like: withEach instead of forEach. Maybe worth a proposal on evolution? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - A server for websites build in Swift > On 26 Apr 2017, at 16:47, J.E. Schotsman via swift-users > wrote: > > > On 26 Apr 2017, at 16:27, Rien wrote: > >> To edit the value in the array itself use: >> >> array[index].number += 1 > > That requires a for loop. > Functional programming lets you write for loops more succinctly. > Why can’t $0 not be used as a reference, like array[index] ? > I've checked, it’s not among the commonly rejected proposals. > > Jan E. > > ___ > 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] edit array
Because you are (trying) to edit a copy.
To edit the value in the array itself use:
array[index].number += 1
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
> On 26 Apr 2017, at 16:15, J.E. Schotsman via swift-users
> wrote:
>
> Simple question: why can’t I edit a variable array with a functional method?
>
> For example:
>
> struct TestStruct
> {
> var number = 0
> }
>
> var array = [TestStruct](repeatElement(TestStruct(), count: 2))
> array.forEach { $0.number += 1 }
>
> Jan E.
> ___
> 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] Alternative to UnicodeScalar
With the Array operations: append or insert
var tmp: [CChar] = [0, 0]
for i in 1 ... 100 {
tmp.insert(0, at: 0)
}
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
> On 09 Apr 2017, at 06:33, Proyb P wrote:
>
> How do I append character A-Z by integer into CChar and benchmark timing how
> fast it’s append compare to UInt8?
>
> var tmp: [CChar] = [0,0]
> for var i in 0...256 {
>tmp[0] = 100
> }
> print(String(cString: &tmp))
>
>
> On Sun, Apr 9, 2017 at 3:17 AM, Proyb P wrote:
> Agree, in some case, I seem to find Cchar is really shine at 10x faster than
> Python from A to Z, 1000x faster than normal Swift? Not sure if there was
> flaw in the time measurement.
>
>
> On Sunday, 9 April 2017, Rien wrote:
> Server-side is usually UTF-8 (not always), so often you don’t really need
> strings.
> As an aside, time measurements are difficult, especially when IO is involved
> there may be thread switches or locks.
>
> I have written some parsers (UTF-8 based) and not yet encountered performance
> problems. (though faster is always better)
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - A server for websites build in Swift
>
>
>
>
>
>
> > On 08 Apr 2017, at 18:19, Proyb P via swift-users
> > wrote:
> >
> > I have found this took about 0.001s to print 256 characters
> > Compare to Python took 0.16s to print 256 characters, see F8 code and
> > have modify to run only one call instead of 1000 iterations.
> > https://gist.github.com/anonymous/18e372e8d0173e77b5c405920d4d3080
> >
> > As this is frequently use for server-side swift that will definitely
> > affected by expensive call, are there any alternative solution for
> > converting Int to character close to Python timing?
> >
> > import Foundation
> > var display: String = ""
> >
> > func printTimeElapsedWhenRunningCode(title: String, operation: ()->()) {
> > let startTime = CFAbsoluteTimeGetCurrent()
> > operation()
> > let timeElapsed = CFAbsoluteTimeGetCurrent() - startTime
> > print("Time elapsed for \(title): \(timeElapsed) s")
> > }
> >
> > printTimeElapsedWhenRunningCode(title: "s1()") {
> > let startingValue = Int(("A" as UnicodeScalar).value) // 65
> > for i in 0 ..< 256 {
> > print(Character(UnicodeScalar(i + startingValue)!))
> > }
> > }
> > ___
> > 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] Alternative to UnicodeScalar
Server-side is usually UTF-8 (not always), so often you don’t really need
strings.
As an aside, time measurements are difficult, especially when IO is involved
there may be thread switches or locks.
I have written some parsers (UTF-8 based) and not yet encountered performance
problems. (though faster is always better)
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift
> On 08 Apr 2017, at 18:19, Proyb P via swift-users
> wrote:
>
> I have found this took about 0.001s to print 256 characters
> Compare to Python took 0.16s to print 256 characters, see F8 code and
> have modify to run only one call instead of 1000 iterations.
> https://gist.github.com/anonymous/18e372e8d0173e77b5c405920d4d3080
>
> As this is frequently use for server-side swift that will definitely affected
> by expensive call, are there any alternative solution for converting Int to
> character close to Python timing?
>
> import Foundation
> var display: String = ""
>
> func printTimeElapsedWhenRunningCode(title: String, operation: ()->()) {
> let startTime = CFAbsoluteTimeGetCurrent()
> operation()
> let timeElapsed = CFAbsoluteTimeGetCurrent() - startTime
> print("Time elapsed for \(title): \(timeElapsed) s")
> }
>
> printTimeElapsedWhenRunningCode(title: "s1()") {
> let startingValue = Int(("A" as UnicodeScalar).value) // 65
> for i in 0 ..< 256 {
> print(Character(UnicodeScalar(i + startingValue)!))
> }
> }
> ___
> 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] Swift 3.1 String(
> On 05 Apr 2017, at 16:26, Maxim Veksler via swift-users
> wrote:
>
> Hi,
>
> Swift 3.1 compiler seems to introduces a new complier warning regarding
> String(describing: )
>
> So this line:
> Log.info("Update name for user \(fbUser)”)
Log.info(“Update name for user \(fbUser ?? “Unknown”)”)
Rien.
>
> Produces the warning: "note: use 'String(describing:)' to silence this
> warning"
>
> and becomes this line
> Log.info("Update name for user \(String(describing: fbUser))")
>
> This new syntax is not very sexy, especially for logging. Any suggestions,
> possibility on the API end of Log to make this warning go away? or write it
> differently.
> ___
> 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] Importing C system libraries
I feel your pain ;-) Just embrace the dark side, it takes a little time to get used to, but chances are you won’t regret it. Btw: I still do my development in Xcode, its just that using the SPM (Swift Package Manager) and git from the command line gives a whole extra dimension to my productivity. I use a large monitor and have two terminal windows open at all times on the left side, and Xcode open on the right. Two monitors would be even better (I think). Xcode is really amazing: when I regenerate the project in a terminal, there is no need to close and reopen xcode. Xcode will collapse the navigator, but otherwise it just refreshes with the new content. Its quite neat to work this way. The only two drawbacks that I have detected so far is that I need to “clean” more in Xcode, and that the old project settings are overwritten, thus if you do a lot of tweaking of the build settings this might not work out all that well. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 27 Mar 2017, at 23:10, Jan Neumüller via swift-users > wrote: > > Is it just me, or is Swift moving to much in a command line direction since > the open sourcing? I feel being left behind as an Xcode user... > > Jan > >> On 27 Mar 2017, at 22:59, Michael Ilseman via swift-users >> wrote: >> >> Sure. At a low level, you can create a module.map file and use -L/-l flags >> in your invocation of Swift. If you want to do so at a higher level, then >> perhaps SwiftPM can. CCing swift-build-dev for the SwiftPM part. >> >> >>> On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users >>> wrote: >>> >>> Idk if this has been asked before, but is there a way to import C libraries >>> into a Swift project without creating a local git repo? Preferably >>> something similar to C where you can just `#include` headers and then >>> specify the link flags (in Package.swift?) >>> >>> It’s getting very cumbersome to make a bunch of empty git repos just to use >>> libglfw or libcairo. >>> ___ >>> 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 > > ___ > 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] Type inference of array element type
I always yield to proof ;-)
hope someone more knowledgable chips in...
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 24 Mar 2017, at 11:53, Toni Suter wrote:
>
> Hmm, I don't know. It also works with other nominal types. For example:
>
> struct S {
> var x: Int
> var y: Int
> }
> let s1 = S(x: 0, y: 1)
> let s2 = S(x: 2, y: 3)
> let arr = [s1, nil, s2]
> print(type(of: arr)) // Array>
>
>> Am 24.03.2017 um 11:30 schrieb Rien :
>>
>> Btw, I just looked it up and it seems to me that inference only works for
>> literals. Which probably means that tuples are out.
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>>
>>> On 24 Mar 2017, at 11:22, Rien via swift-users
>>> wrote:
>>>
>>> IMO this is a boundary problem.
>>> How far do you want to go in letting the compiler deduce the actual type?
>>> It is possible to make very elaborate constructs that would basically
>>> default to a complex tuple/array/dictionary construct with only Any?’s in
>>> them. (well, the dict would require a Hashable too)
>>>
>>> Besides, the recent discussion on compile times illustrates another angle
>>> to this problem: if type inference is used extensively, compile times go to
>>> infinite…
>>>
>>> So while I do not know if this is a bug or not, I would recommend not to
>>> use it anyhow.
>>>
>>> Regards,
>>> Rien
>>>
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>>
>>>
>>>
>>>
>>>
>>>> On 24 Mar 2017, at 11:08, Toni Suter via swift-users
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> If I declare a variable and initialize it with an array literal whose
>>>> elements are integer literals and nil literals,
>>>> the compiler will infer the type Array> for that variable:
>>>>
>>>> let arr = [1, nil, 3]
>>>> print(type(of: arr)) // Array>
>>>>
>>>> However, that only works with nominal types such as Int and String. If I
>>>> do the same thing with an array of tuples,
>>>> I get a compile error:
>>>>
>>>> let arr = [(1, false), nil, (3, true)] // error: type of
>>>> expression is ambiguous without more context
>>>> print(type(of: arr))
>>>>
>>>> Why can't the compiler infer the type Array> in this
>>>> example? Is there a reason for this or is it a bug?
>>>>
>>>> Thanks and best regards,
>>>> Toni
>>>>
>>>> ___
>>>> 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
>>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Type inference of array element type
Btw, I just looked it up and it seems to me that inference only works for literals. Which probably means that tuples are out. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 24 Mar 2017, at 11:22, Rien via swift-users wrote: > > IMO this is a boundary problem. > How far do you want to go in letting the compiler deduce the actual type? > It is possible to make very elaborate constructs that would basically default > to a complex tuple/array/dictionary construct with only Any?’s in them. > (well, the dict would require a Hashable too) > > Besides, the recent discussion on compile times illustrates another angle to > this problem: if type inference is used extensively, compile times go to > infinite… > > So while I do not know if this is a bug or not, I would recommend not to use > it anyhow. > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Balancingrock > Project: http://swiftfire.nl > > > > > >> On 24 Mar 2017, at 11:08, Toni Suter via swift-users >> wrote: >> >> Hi, >> >> If I declare a variable and initialize it with an array literal whose >> elements are integer literals and nil literals, >> the compiler will infer the type Array> for that variable: >> >> let arr = [1, nil, 3] >> print(type(of: arr)) // Array> >> >> However, that only works with nominal types such as Int and String. If I do >> the same thing with an array of tuples, >> I get a compile error: >> >> let arr = [(1, false), nil, (3, true)] // error: type of >> expression is ambiguous without more context >> print(type(of: arr)) >> >> Why can't the compiler infer the type Array> in this >> example? Is there a reason for this or is it a bug? >> >> Thanks and best regards, >> Toni >> >> ___ >> 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 ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Type inference of array element type
IMO this is a boundary problem. How far do you want to go in letting the compiler deduce the actual type? It is possible to make very elaborate constructs that would basically default to a complex tuple/array/dictionary construct with only Any?’s in them. (well, the dict would require a Hashable too) Besides, the recent discussion on compile times illustrates another angle to this problem: if type inference is used extensively, compile times go to infinite… So while I do not know if this is a bug or not, I would recommend not to use it anyhow. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 24 Mar 2017, at 11:08, Toni Suter via swift-users > wrote: > > Hi, > > If I declare a variable and initialize it with an array literal whose > elements are integer literals and nil literals, > the compiler will infer the type Array> for that variable: > > let arr = [1, nil, 3] > print(type(of: arr)) // Array> > > However, that only works with nominal types such as Int and String. If I do > the same thing with an array of tuples, > I get a compile error: > > let arr = [(1, false), nil, (3, true)]// error: type of > expression is ambiguous without more context > print(type(of: arr)) > > Why can't the compiler infer the type Array> in this > example? Is there a reason for this or is it a bug? > > Thanks and best regards, > Toni > > ___ > 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] @noReturn
Excellent!
Love this list ;-)
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 24 Mar 2017, at 10:12, Philip Erickson wrote:
>
> I believe returning Never does what you want, e.g.
>
>
> import Foundation
>
> func findReasonAndTerminate() -> Never
> {
>let reason: String = findReason()
>fatalError(reason)
> }
>
> func findReason() -> String
> {
> return "some reason"
> }
>
> func buildData() -> Data?
> {
> return nil
> }
>
> guard let data = buildData() else { findReasonAndTerminate() }
>
>
> On Fri, Mar 24, 2017 at 3:02 AM, Rien via swift-users
> wrote:
> Is there any way to mark a function as “no return”?
>
> Reason: The compiler generates an error when the else block from a guard does
> not terminate the execution by either a return or a fatalError. I want to
> call out to a function and raise the fatalError in that function.
>
> func findReasonAndTerminate() {
>let reason: String = ….
>fatalError(reason)
> }
>
> main.swift:
>
> guard let data = buildData() else { findReasonAndTerminate() }
>
>
> Currently the work around is to add another fatalError like this:
>
> guard let data = buildData() else { findReasonAndTerminate(); fatalError }
>
>
> but it would be nice to have some attribute like @noReturn:
>
> @noReturn
> func findReasonAndTerminate() { … }
>
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
> ___
> 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
[swift-users] @noReturn
Is there any way to mark a function as “no return”?
Reason: The compiler generates an error when the else block from a guard does
not terminate the execution by either a return or a fatalError. I want to call
out to a function and raise the fatalError in that function.
func findReasonAndTerminate() {
let reason: String = ….
fatalError(reason)
}
main.swift:
guard let data = buildData() else { findReasonAndTerminate() }
Currently the work around is to add another fatalError like this:
guard let data = buildData() else { findReasonAndTerminate(); fatalError }
but it would be nice to have some attribute like @noReturn:
@noReturn
func findReasonAndTerminate() { … }
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Improving compilation times?
> On 23 Mar 2017, at 10:27, Rien wrote:
>
> Just tried it, did not work on the command line either, though with a simple
> message “build commands failed”
>
> The following command line however does work:
>
> xcodebuild -scheme Swiftfire clean build OTHER_SWIFT_FLAGS="-Xfrontend
> -debug-time-function-bodies" | grep .[0-9]ms | grep -v ^0.[0-9]ms | sort -nr
> > culprits.txt
>
> (I found that line in the link provided previously, just modified it to work
> with a workspace and with my scheme)
Oeps, “without a workspace” !!!
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
>> On 23 Mar 2017, at 09:58, piotr gorzelany wrote:
>>
>> Hi Mark,
>>
>> Thanks for the answer, its great to know that somebody is working on it!
>>
>> I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode
>> in the Other Swift Flags section but that gives me an error when compiling
>>
>> :0: error: unknown argument: '-debug-time-expression-type-checking'
>>
>> Should I rather compile it on the command line using this option?
>>
>> Regards,
>> Piotr
>>
>> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users
>> napisał:
>>
>>> On Mar 23, 2017, at 12:32 AM, Rien via swift-users
>>> wrote:
>>>
>>>
>>>> On 23 Mar 2017, at 08:27, David Hart wrote:
>>>>
>>>> Yes, it's best to avoid concatenating strings with +. Not only for
>>>> performance reasons, but it's also less readable than string interpolation:
>>>>
>>>> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ??
>>>> "?")\n”
>>>
>>> Concatenation may cause the increase, but this solved it too:
>>>
>>> let (clientIpOrNil, serviceOrNil) =
>>> sockaddrDescription(info.pointee.ai_addr)
>>> let clientIp = clientIpOrNil ?? "?"
>>> let service = serviceOrNil ?? "?"
>>> str += "No: \(count), HostIp: " + clientIp + " at port: " + service +
>>> "\n”
>>
>> To make a long story short, expressions combining the results of
>> nil-coalescing with other operators tend to be very slow to type check at
>> the moment. I’m working on fixing this (really the more general issue as it
>> is not specific to ?? but I’ve seen several bug reports that involve that
>> operator).
>>
>> I added another command-line option to help track issues like this down (at
>> the expression level, rather than function level):
>> -Xfrontend -debug-time-expression-type-checking
>>
>> If you use that you’ll see a line for every expression that is type-checked,
>> with source location information, and the time to type check the expression.
>> In some cases we may not have valid source information (I believe this
>> generally happens for things the compiler synthesizes rather than user
>> code), and you’ll see ‘’ rather than the file/line/column info.
>>
>> Mark
>>
>>
>>>
>>> Regards,
>>> Rien.
>>>
>>>
>>>>
>>>> On 23 Mar 2017, at 08:11, Rien via swift-users
>>>> wrote:
>>>>
>>>>> Thanks for that link, used it to track down the worst compile time
>>>>> offender:
>>>>>
>>>>> This piece of code:
>>>>>
>>>>> public func logAddrInfoIPAddresses(_ infoPtr:
>>>>> UnsafeMutablePointer) -> String {
>>>>>
>>>>> let addrInfoNil: UnsafeMutablePointer? = nil
>>>>> var count: Int = 0
>>>>> var info: UnsafeMutablePointer = infoPtr
>>>>> var str: String = ""
>>>>>
>>>>> while info != addrInfoNil {
>>>>>
>>>>> let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>>>>> str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " +
>>>>> (service ?? "?") + "\n"
>>>>> count += 1
>>>>> info = info.pointee.ai_next
>>>>> }
>>>>> return str
>>>>> }
>>>>>
>>>>> Took 38 seconds to compile.
>>>>>
>&g
Re: [swift-users] Improving compilation times?
Just tried it, did not work on the command line either, though with a simple
message “build commands failed”
The following command line however does work:
xcodebuild -scheme Swiftfire clean build OTHER_SWIFT_FLAGS="-Xfrontend
-debug-time-function-bodies" | grep .[0-9]ms | grep -v ^0.[0-9]ms | sort -nr >
culprits.txt
(I found that line in the link provided previously, just modified it to work
with a workspace and with my scheme)
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 23 Mar 2017, at 09:58, piotr gorzelany wrote:
>
> Hi Mark,
>
> Thanks for the answer, its great to know that somebody is working on it!
>
> I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode
> in the Other Swift Flags section but that gives me an error when compiling
>
> :0: error: unknown argument: '-debug-time-expression-type-checking'
>
> Should I rather compile it on the command line using this option?
>
> Regards,
> Piotr
>
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users
> napisał:
>
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users
> > wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for
> >> performance reasons, but it's also less readable than string interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ??
> >> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) =
> > sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " + service
> > + "\n”
>
> To make a long story short, expressions combining the results of
> nil-coalescing with other operators tend to be very slow to type check at the
> moment. I’m working on fixing this (really the more general issue as it is
> not specific to ?? but I’ve seen several bug reports that involve that
> operator).
>
> I added another command-line option to help track issues like this down (at
> the expression level, rather than function level):
> -Xfrontend -debug-time-expression-type-checking
>
> If you use that you’ll see a line for every expression that is type-checked,
> with source location information, and the time to type check the expression.
> In some cases we may not have valid source information (I believe this
> generally happens for things the compiler synthesizes rather than user code),
> and you’ll see ‘’ rather than the file/line/column info.
>
> Mark
>
>
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users
> >> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time
> >>> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>> let addrInfoNil: UnsafeMutablePointer? = nil
> >>> var count: Int = 0
> >>> var info: UnsafeMutablePointer = infoPtr
> >>> var str: String = ""
> >>>
> >>> while info != addrInfoNil {
> >>>
> >>> let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
> >>> str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: "
> >>> + (service ?? "?") + "\n"
> >>> count += 1
> >>> info = info.pointee.ai_next
> >>> }
> >>> return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing the “str” assignment:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>> let addrInfoNil: UnsafeMutablePointer? = nil
> >>> var count: Int = 0
> >>> var info: UnsafeMutablePointer = infoPtr
> >>> var str: String = ""
> >>>
> >>> while info != addrInfoNil {
> >>>
> >>> l
Re: [swift-users] Improving compilation times?
> On 23 Mar 2017, at 08:27, David Hart wrote:
>
> Yes, it's best to avoid concatenating strings with +. Not only for
> performance reasons, but it's also less readable than string interpolation:
>
> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? "?")\n”
Concatenation may cause the increase, but this solved it too:
let (clientIpOrNil, serviceOrNil) =
sockaddrDescription(info.pointee.ai_addr)
let clientIp = clientIpOrNil ?? "?"
let service = serviceOrNil ?? "?"
str += "No: \(count), HostIp: " + clientIp + " at port: " + service +
"\n”
Regards,
Rien.
>
> On 23 Mar 2017, at 08:11, Rien via swift-users wrote:
>
>> Thanks for that link, used it to track down the worst compile time offender:
>>
>> This piece of code:
>>
>> public func logAddrInfoIPAddresses(_ infoPtr:
>> UnsafeMutablePointer) -> String {
>>
>>let addrInfoNil: UnsafeMutablePointer? = nil
>>var count: Int = 0
>>var info: UnsafeMutablePointer = infoPtr
>>var str: String = ""
>>
>>while info != addrInfoNil {
>>
>>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>>str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " +
>> (service ?? "?") + "\n"
>>count += 1
>>info = info.pointee.ai_next
>>}
>>return str
>> }
>>
>> Took 38 seconds to compile.
>>
>> Removing the “str” assignment:
>>
>> public func logAddrInfoIPAddresses(_ infoPtr:
>> UnsafeMutablePointer) -> String {
>>
>>let addrInfoNil: UnsafeMutablePointer? = nil
>>var count: Int = 0
>>var info: UnsafeMutablePointer = infoPtr
>>var str: String = ""
>>
>>while info != addrInfoNil {
>>
>>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: "
>> + (service ?? "?") + "\n"
>>count += 1
>>info = info.pointee.ai_next
>>}
>>return str
>> }
>>
>> Brought it down to 6.6ms
>>
>> Obviously I have to rewrite, but it does show how just one line of code can
>> be responsible for approx 80% of the compile time.
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>>
>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users
>>> wrote:
>>>
>>>>
>>>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users
>>>> wrote:
>>>>
>>>> Hi, I hope I reached the right mailing list to ask a question about
>>>> tooling.
>>>>
>>>> Can somebody from the compiler or Xcode team share some tips on how to
>>>> improve compilation times of larger Swift projects?
>>>>
>>>> I am an iOS developer and the largest issue my team has with Swift so far
>>>> is that when the project gets semi large (~30 000 lines) the compilation
>>>> times start to be high (~10 minutes from clean). This is a MAJOR downside
>>>> since iOS development oftentimes requires rapid changes to UI or logic.
>>>> Every person of my team compiles a project at least 10 times a day to test
>>>> new features or functionalities. When compilation times start to be higher
>>>> than 10 minutes that gets us to ~1.5h a day of developer time spend just
>>>> on compiling. Not to mention the focus lost when this is happening.
>>>>
>>>> I know the Swift Evolution list is buzzing with new ideas and features but
>>>> from my experience the compilation times is a CRITICAL thing to improve in
>>>> the next Swift release since it cost real money to waste all those
>>>> developer hours. Just think of all the hours lost on compiling across all
>>>> Swift devs worldwide and you will get to probably dozens of thousand of
>>>> dev hours a day.
>>>>
>>>> Is the core compiler team going to address compilation performance in the
>>>> next release?
>>>>
>>>> Maybe there is an existing solution to long compilation times that w
Re: [swift-users] Improving compilation times?
Thanks for that link, used it to track down the worst compile time offender:
This piece of code:
public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer)
-> String {
let addrInfoNil: UnsafeMutablePointer? = nil
var count: Int = 0
var info: UnsafeMutablePointer = infoPtr
var str: String = ""
while info != addrInfoNil {
let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " +
(service ?? "?") + "\n"
count += 1
info = info.pointee.ai_next
}
return str
}
Took 38 seconds to compile.
Removing the “str” assignment:
public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer)
-> String {
let addrInfoNil: UnsafeMutablePointer? = nil
var count: Int = 0
var info: UnsafeMutablePointer = infoPtr
var str: String = ""
while info != addrInfoNil {
let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
//str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " +
(service ?? "?") + "\n"
count += 1
info = info.pointee.ai_next
}
return str
}
Brought it down to 6.6ms
Obviously I have to rewrite, but it does show how just one line of code can be
responsible for approx 80% of the compile time.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 22 Mar 2017, at 23:41, Greg Parker via swift-users
> wrote:
>
>>
>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users
>> wrote:
>>
>> Hi, I hope I reached the right mailing list to ask a question about tooling.
>>
>> Can somebody from the compiler or Xcode team share some tips on how to
>> improve compilation times of larger Swift projects?
>>
>> I am an iOS developer and the largest issue my team has with Swift so far is
>> that when the project gets semi large (~30 000 lines) the compilation times
>> start to be high (~10 minutes from clean). This is a MAJOR downside since
>> iOS development oftentimes requires rapid changes to UI or logic. Every
>> person of my team compiles a project at least 10 times a day to test new
>> features or functionalities. When compilation times start to be higher than
>> 10 minutes that gets us to ~1.5h a day of developer time spend just on
>> compiling. Not to mention the focus lost when this is happening.
>>
>> I know the Swift Evolution list is buzzing with new ideas and features but
>> from my experience the compilation times is a CRITICAL thing to improve in
>> the next Swift release since it cost real money to waste all those developer
>> hours. Just think of all the hours lost on compiling across all Swift devs
>> worldwide and you will get to probably dozens of thousand of dev hours a day.
>>
>> Is the core compiler team going to address compilation performance in the
>> next release?
>>
>> Maybe there is an existing solution to long compilation times that we don't
>> know of? It would be great if anybody could share.
>> I was thinking maybe of dividing the app into multiple frameworks since I
>> think frameworks are compiled only once only on change?
>
> Build time is always a goal. Pretty much every version of Swift has had
> changes intended to improve compilation time or decrease the frequency of
> recompilation.
>
> Often a large part of the build time is spent in a handful of places where
> the compiler's type inference system behaves poorly. You can use the
> -debug-time-function-bodies and -debug-time-expression-type-checking flags to
> look for these places. You can often get huge decreases in compile time by
> adding an explicit type declaration in the right place in order to simplify
> the type inference engine's job.
>
> Here's a walkthough of one such analysis:
> Profiling your Swift compilation times
> http://irace.me/swift-profiling
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
> ___
> 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] It seems like we really need an #include preprocessor directive?
> On 11 Mar 2017, at 21:12, Edward Connell via swift-users
> wrote:
>
> Observations about difining an object
> • Structs can't inherit and classes shouldn't inherit, final concrete
> types should be flat
Why?
I always default to the position that we should do what works. Get the project
done.
Sure sometimes we do become language lawyers, but don’t let that force you into
a corner.
If you need inheritance, use it. AFAIIC OOP is a first class citizen in Swift.
> • Protocols need to be adopted by the final concrete type, otherwise
> constraint specializations aren't correctly applied
> This creates a really ugly code duplication situation when you have multiple
> object variants that adopt the same protocols.
>
> The storage declaration, common initialization, common didSet, etc... for
> protocol member variables must be duplicated for every instance.
> If I have 20 objects that have the same base set of 15 vars, this turns into
> a maintenance/bug nightmare.
What about mimicking inheritance?:
struct FooBar {
var foo: Int
var bar: Int
}
protocol FooBarManipulation {
var fooBar: FooBar { get set }
func doSomethingWithFooBar()
}
extension FooBarManipulation {
func doSomthingWithFooBar() { … }
}
class SomeClass: FooBarManipulation {
var fooBar: FooBar?
}
struct SomeStruct: FooBarManipulation {
var fooBar = FooBar(...)
}
Regards,
Rien.
>
> I noticed the use of GYB in the swift source code.
> I don't want to involve python in anything I do, and I don't want to mess up
> my code/build with all that stuff.
>
> It seems that an easy workaround would be an #include statement.
> The boiler plate can be put in a separate file and included wherever it's
> needed.
> One piece of code, one tool, one set of bugs.
>
> Has this been considered? Or is there a better way to handle this problem.
>
> Thanks, Ed
> ___
> 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] Generics with variable argument lists
Ah!, yes that would be perfect!
Many thanks!
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 09 Mar 2017, at 12:36, Ole Begemann wrote:
>
> On 09/03/2017 11:05, Rien via swift-users wrote:
>> I am trying to achieve the following:
>>
>> enum FunctionResult {
>> case success(T)
>> case error(String)
>> }
>>
>> func tester(test: (…) -> FunctionResult, onError: (String) -> T) -> T {
>> …
>> }
>>
>> The problem is of course the (…) that simply does not work.
>>
>> I would like to use this generic with a variety of different signatures,
>> i.e.:
>>
>> let result1 = tester(test: myfunc1(param: 26) -> FunctionResult,
>> onError: { … handle the error ... })
>> let result2 = tester(test: myfunc2(param: “A String") ->
>> FunctionResult, onError: { … handle the error ... })
>> let result3 = tester(test: myfunc3(param: 26, param2: “String") ->
>> FunctionResult, onError: { … handle the error ... })
>>
>> Is this at all possible?
>
> This should do it:
>
>func tester(test: @autoclosure () -> FunctionResult,
>onError: (String) -> T) -> T {
>switch test() {
>case .success(let value): return value
>case .error(let error): return onError(error)
>}
>}
>
> The insight is that you don't really want to pass a function in the first
> parameter, but only the _result_ of that function call. The @autoclosure
> attribute then makes sure that the expression you pass to tester is only
> evaluated inside tester. You can leave it out if you want (if you do, replace
> `switch test()` with `switch test`).
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] Generics with variable argument lists
I am trying to achieve the following:
enum FunctionResult {
case success(T)
case error(String)
}
func tester(test: (…) -> FunctionResult, onError: (String) -> T) -> T {
…
}
The problem is of course the (…) that simply does not work.
I would like to use this generic with a variety of different signatures, i.e.:
let result1 = tester(test: myfunc1(param: 26) -> FunctionResult, onError:
{ … handle the error ... })
let result2 = tester(test: myfunc2(param: “A String") -> FunctionResult,
onError: { … handle the error ... })
let result3 = tester(test: myfunc3(param: 26, param2: “String") ->
FunctionResult, onError: { … handle the error ... })
Is this at all possible?
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] What is the intended response to Array change notification for dependents?
I don’t think there is a single answer to this. It is all highly dependant on what the application does with the info. Sometimes it will indeed be necessary to rebuild the entire gui, other times it is enough to simply insert a new table cell. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 07 Mar 2017, at 03:56, Edward Connell via swift-users > wrote: > > I would like to have an Array implementation where I get more information > than just "the whole thing changed". > As a value type I get it, but lets say it's a list of 500 image info structs > and it's bound to UI. You change one item, now the whole array changes and > you have to rebuild the entire visual tree right? Rebuilding the state of > dependent objects can be really expensive, not just UI things. > > Is there some efficient strategy that the library designers intended for this > situation? > It seems like a really common and obvious scenario. > Insights and suggestions are appreciated. > > Thanks, Ed > > > ___ > 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] How to optionally link swift framework into another framework
The way I look at it is that Swift wants all symbols resolved when linking.
C++ is probably very lenient toward full resolution, and as long as you know
that a certain unresolved reference is not used, you can safely ignore the
warning.
Or maybe the C++ compiler is just very clever and can figure out that the
reference is never used?
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 06 Mar 2017, at 18:09, Jakub Bednář wrote:
>
> Hi Rien,
>
> looks like a good way around my problem.
>
> Still I wonder why this does not work in Swift as it does work in Objective-C
> or even in strongly typed checked C++.
>
> Maybe it is some kind of Swift’s security measure to avoid hard-to-debug bugs
> in C++ caused by virtual table inconsistencies.
>
> Anyway, thanks for the help.
>
> J.
>
>
>> On Mar 6, 2017, at 6:01 PM, Rien wrote:
>>
>> Well, that was a bit short…
>>
>> When you want to use logging, define the ACC “USE_LOGGING” in the build
>> settings.
>> When you don’t want to use logging, don’t define the ACC.
>>
>> PS: You can get my logging framework from github:
>> https://github.com/Balancingrock/SwifterLog
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>>
>>> On 06 Mar 2017, at 17:58, Rien wrote:
>>>
>>> You need conditional compilation.
>>>
>>> Called “Active Compilation Conditions” in the build settings.
>>>
>>> For example define a ACC of “USE_LOGGING”
>>>
>>> Then in your code:
>>>
>>> #if USE_LOGGING
>>>
>>> import Logging
>>>
>>> #else
>>>
>>> struct Logging {
>>> func debug(message: string) {}
>>> }
>>>
>>> #endif
>>>
>>>
>>>
>>>
>>> Regards,
>>> Rien
>>>
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>>
>>>
>>>
>>>
>>>
On 06 Mar 2017, at 17:26, Jakub Bednář via swift-users
wrote:
Hello everyone,
I am trying to add optional logging into my framework, but for sake of
this question, lets assume I want to add optional logging into an app. I
have created an example with following setup:
1. Logging.framework declares
public protocol Logging {
func debug(message: String)
}
and I have build the framework for the app to see it.
2. Application has
import Logging
public class Engine {
let logger: Logging?
public init(withLogger logger: Logging? = nil) {
self.logger = logger
}
public work() {
self.logger?.debug(“Working”)
}
}
Now I don’t have the Logging.framework in Embed Binaries nor Link
Frameworks lists. My app builds ok, but then fails to start telling me
that Logging.framework was not loaded. I checked the binary using otool -L
and Logging.framework is still referenced by the binary. Is there any way
how to achieve my goal? This would be trivial with Objective-C and I still
can’t figure it out in Swift.
Thanks a lot,
J.
___
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] How to optionally link swift framework into another framework
Well, that was a bit short…
When you want to use logging, define the ACC “USE_LOGGING” in the build
settings.
When you don’t want to use logging, don’t define the ACC.
PS: You can get my logging framework from github:
https://github.com/Balancingrock/SwifterLog
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 06 Mar 2017, at 17:58, Rien wrote:
>
> You need conditional compilation.
>
> Called “Active Compilation Conditions” in the build settings.
>
> For example define a ACC of “USE_LOGGING”
>
> Then in your code:
>
> #if USE_LOGGING
>
> import Logging
>
> #else
>
> struct Logging {
> func debug(message: string) {}
> }
>
> #endif
>
>
>
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
>> On 06 Mar 2017, at 17:26, Jakub Bednář via swift-users
>> wrote:
>>
>> Hello everyone,
>>
>> I am trying to add optional logging into my framework, but for sake of this
>> question, lets assume I want to add optional logging into an app. I have
>> created an example with following setup:
>>
>> 1. Logging.framework declares
>>
>> public protocol Logging {
>> func debug(message: String)
>> }
>>
>> and I have build the framework for the app to see it.
>>
>> 2. Application has
>>
>> import Logging
>>
>> public class Engine {
>>
>> let logger: Logging?
>>
>> public init(withLogger logger: Logging? = nil) {
>> self.logger = logger
>> }
>>
>> public work() {
>> self.logger?.debug(“Working”)
>> }
>> }
>>
>> Now I don’t have the Logging.framework in Embed Binaries nor Link Frameworks
>> lists. My app builds ok, but then fails to start telling me that
>> Logging.framework was not loaded. I checked the binary using otool -L and
>> Logging.framework is still referenced by the binary. Is there any way how to
>> achieve my goal? This would be trivial with Objective-C and I still can’t
>> figure it out in Swift.
>>
>> Thanks a lot,
>>
>> J.
>>
>> ___
>> 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] How to optionally link swift framework into another framework
You need conditional compilation.
Called “Active Compilation Conditions” in the build settings.
For example define a ACC of “USE_LOGGING”
Then in your code:
#if USE_LOGGING
import Logging
#else
struct Logging {
func debug(message: string) {}
}
#endif
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 06 Mar 2017, at 17:26, Jakub Bednář via swift-users
> wrote:
>
> Hello everyone,
>
> I am trying to add optional logging into my framework, but for sake of this
> question, lets assume I want to add optional logging into an app. I have
> created an example with following setup:
>
> 1. Logging.framework declares
>
> public protocol Logging {
> func debug(message: String)
> }
>
> and I have build the framework for the app to see it.
>
> 2. Application has
>
> import Logging
>
> public class Engine {
>
> let logger: Logging?
>
> public init(withLogger logger: Logging? = nil) {
> self.logger = logger
> }
>
> public work() {
> self.logger?.debug(“Working”)
> }
> }
>
> Now I don’t have the Logging.framework in Embed Binaries nor Link Frameworks
> lists. My app builds ok, but then fails to start telling me that
> Logging.framework was not loaded. I checked the binary using otool -L and
> Logging.framework is still referenced by the binary. Is there any way how to
> achieve my goal? This would be trivial with Objective-C and I still can’t
> figure it out in Swift.
>
> Thanks a lot,
>
> J.
>
> ___
> 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] Function conforming to a typealias
Just tried it, unfortunately it does not achieve what I wanted. As soon as a
parameter is added, the compiler complains (rightly so) about ignoring an
argument.
Oh well, at least I get warnings when parameters are added so that I don’t have
to remember which functions need a touch-up.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 18 Feb 2017, at 12:05, Rien via swift-users wrote:
>
> It feels a bit strange to write it like that, but yes, that would work.
> Thanks!
>
> (It will prevent me from having to touch up old functions when adding more
> parameters to the signature as the project evolves)
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
>> On 18 Feb 2017, at 11:52, Adrian Zubarev
>> wrote:
>>
>> Not sure what you’re trying to solve there but you could use it like this
>> with closures:
>>
>> typealias Function = (Int, Bool) -> String?
>>
>> let myGreatFunc1: Function = { _ in return nil /* or whatever you need there
>> */ }
>> let myGreatFunc2: Function = { _ in return nil }
>>
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 18. Februar 2017 um 11:47:26, Rien via swift-users
>> (swift-users@swift.org) schrieb:
>>
>>> I want to create a few functions that all have the same signature.
>>>
>>> The signature is defined in a typealias
>>>
>>> Is there any way to shortcut the function definition, or alternatively
>>> ensure that the function signature will always be equal to the typealias?
>>>
>>> Examplecode:
>>>
>>> typealias Mysig = (Int, Bool) -> String?
>>>
>>> func myGreatFunc1:Mysig {…}
>>>
>>> func myGreatFunc2:Mysig { …}
>>>
>>> Alternatively
>>>
>>> @conformsTo(Mysig)
>>> func myGreatFunc1(_ a:Int, _ b: Bool) -> String? {…}
>>>
>>> Regards,
>>> Rien
>>>
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Function conforming to a typealias
It feels a bit strange to write it like that, but yes, that would work. Thanks!
(It will prevent me from having to touch up old functions when adding more
parameters to the signature as the project evolves)
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 18 Feb 2017, at 11:52, Adrian Zubarev
> wrote:
>
> Not sure what you’re trying to solve there but you could use it like this
> with closures:
>
> typealias Function = (Int, Bool) -> String?
>
> let myGreatFunc1: Function = { _ in return nil /* or whatever you need there
> */ }
> let myGreatFunc2: Function = { _ in return nil }
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 18. Februar 2017 um 11:47:26, Rien via swift-users (swift-users@swift.org)
> schrieb:
>
>> I want to create a few functions that all have the same signature.
>>
>> The signature is defined in a typealias
>>
>> Is there any way to shortcut the function definition, or alternatively
>> ensure that the function signature will always be equal to the typealias?
>>
>> Examplecode:
>>
>> typealias Mysig = (Int, Bool) -> String?
>>
>> func myGreatFunc1:Mysig {…}
>>
>> func myGreatFunc2:Mysig { …}
>>
>> Alternatively
>>
>> @conformsTo(Mysig)
>> func myGreatFunc1(_ a:Int, _ b: Bool) -> String? {…}
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>>
>> ___
>> 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] Function conforming to a typealias
Sorry: “prevent me from” should have been “allow me to avoid”
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 18 Feb 2017, at 12:05, Rien wrote:
>
> It feels a bit strange to write it like that, but yes, that would work.
> Thanks!
>
> (It will prevent me from having to touch up old functions when adding more
> parameters to the signature as the project evolves)
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
>> On 18 Feb 2017, at 11:52, Adrian Zubarev
>> wrote:
>>
>> Not sure what you’re trying to solve there but you could use it like this
>> with closures:
>>
>> typealias Function = (Int, Bool) -> String?
>>
>> let myGreatFunc1: Function = { _ in return nil /* or whatever you need there
>> */ }
>> let myGreatFunc2: Function = { _ in return nil }
>>
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 18. Februar 2017 um 11:47:26, Rien via swift-users
>> (swift-users@swift.org) schrieb:
>>
>>> I want to create a few functions that all have the same signature.
>>>
>>> The signature is defined in a typealias
>>>
>>> Is there any way to shortcut the function definition, or alternatively
>>> ensure that the function signature will always be equal to the typealias?
>>>
>>> Examplecode:
>>>
>>> typealias Mysig = (Int, Bool) -> String?
>>>
>>> func myGreatFunc1:Mysig {…}
>>>
>>> func myGreatFunc2:Mysig { …}
>>>
>>> Alternatively
>>>
>>> @conformsTo(Mysig)
>>> func myGreatFunc1(_ a:Int, _ b: Bool) -> String? {…}
>>>
>>> Regards,
>>> Rien
>>>
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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
[swift-users] Function conforming to a typealias
I want to create a few functions that all have the same signature.
The signature is defined in a typealias
Is there any way to shortcut the function definition, or alternatively ensure
that the function signature will always be equal to the typealias?
Examplecode:
typealias Mysig = (Int, Bool) -> String?
func myGreatFunc1:Mysig {…}
func myGreatFunc2:Mysig { …}
Alternatively
@conformsTo(Mysig)
func myGreatFunc1(_ a:Int, _ b: Bool) -> String? {…}
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] ambiguous minus operator
I don’t know about the candidates
But the uptimeNanoseconds is a UInt64 and as such you should probably use
substractWithOverflow.
var a: UInt64 = 12
var b: UInt64 = 25
let result = UInt64.subtractWithOverflow(a, b)
if result.overflow {
print("Overflow")
} else {
let answer = result.0
}
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 16 Feb 2017, at 16:56, J.E. Schotsman via swift-users
> wrote:
>
> Hello,
>
> I am trying to define an operator that subtracts dispatch times:
>
> #import Dispatch
>
> func -( time1: DispatchTime, time2: DispatchTime ) -> DispatchTimeInterval
> {
> return DispatchTimeInterval.nanoseconds( time2.uptimeNanoseconds -
> time1.uptimeNanoseconds )
> }
>
> Compiler says: Ambiguous use of operator ‘-'
> Found this candidate
> Found this candidate
>
> As usual the candidates are unknown.
>
> What am I doing wrong?
>
> Jan E.
> ___
> 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] UnsafePointer to UInt64
Excellent! I had not seen the bitPattern initializer before… Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 16 Feb 2017, at 14:47, Martin R wrote: > > // Int to pointer: > let ptr = UnsafePointer(bitPattern: 123)! > print(ptr) // 0x007b > > // Pointer to Int: > let int = Int(bitPattern: ptr) > print(int) // 123 > > Int has the same size as a pointer on both 32-bit and 64-bit platforms. > > Regards, Martin > >> On 16 Feb 2017, at 14:27, Rien via swift-users wrote: >> >> What would be the easiest (and fastest) way to convert a pointer to an >> (unsigned)integer? >> >> Ptr -> String -> Int >> >> seems a bit cumbersome to me :-) >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Balancingrock >> Project: http://swiftfire.nl >> >> >> >> >> >> ___ >> 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
[swift-users] UnsafePointer to UInt64
What would be the easiest (and fastest) way to convert a pointer to an (unsigned)integer? Ptr -> String -> Int seems a bit cumbersome to me :-) Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse
> On 09 Feb 2017, at 18:29, Cihat Gündüz via swift-evolution > wrote: > > @Jan: Your arguments are very subjective if not even insulting and derogatory > to many people who invest a lot of time and effort in crafting those things > you despise so openly. Here are just a few example quotes for you to reflect > your language: > > "I despise fp“, „is so annoying“, "made Swift imo a worse language“, "I hate > ‚modern' or as I call it ugly“, "Today’s standards are a bag of pain“, > "crappy sites als Facebook, Twitter, Instagram, Stackoverflow, add lots of > other 'cool' sites“, "I can’t stand scrolling“, "I hate both“, "todays > absolutely useless crap“, … > > Please be aware that this behavior is against the Code of Conduct of the > Swift Community. Let’s try to stay objective and justify different opinions > rationally instead of personally. Of course it is valid for you to say that > you don’t like FP or that you don’t like how the world is changing in > general. But please be aware that you have to add the reason why you think it > is so in detail, so we understand your thinking and can overcome changes to > the wrong direction. Senctences like „I despise FP“ without any explanation > are not a form of constructive feedback though, nobody will learn anything > from that kind of thing. Currently you’re merely expressing your anger here, > no more, no less. I don’t think he did. He expressed his opinions rather forcefully, but we all tick different. He did not call anybody out specifically. And just because somebody spend a lot of time on something does not make it great. And maybe they need to hear it this way to “get the message”. Sugar coating can do a lot of harm. Btw: this does remind me of some of things I heard about a former -too early deceased- leader of apple... Rien. > > > @Jens: One of the biggest reasons I’m all for Discourse is the fact that it’s > open source. What this implies is: You know exactly what happens with the > data you save there, and, there is no dependency on a third-party service > which could change or even close over time. This is why I’m against > groups.io, GitHub Issues or any other non-open source solution. What it also > means is: If the open source tool we decided to go for (Discourse) doesn’t > have good support for emails yet, we can implement it ourselves, improve the > existing support or add a bridge to another open source tool that can deal > with that. > > -- > Cihat Gündüz > > Am 9. Februar 2017 um 15:59:33, Jan Neumüller via swift-evolution > (swift-evolut...@swift.org) schrieb: > >> Well, if the community likes it so much. Have fun with it. I will leave as I >> have left the Developer Forums at Apple because they became unusable. >> >> >>> On 9 Feb 2017, at 15:17, Adrian Zubarev >>> wrote: >>> >>> The quote below made my day dear Swift friend as I might remind you that if >>> modern is associated with hate in your mind, then the modern programming >>> language called Swift would probably be a bad choice. >>> >>> >> I starting to think that myself. I was very active at the beginning of Swift >> (way before the open sourcing) but I absolutely don’t like the increasing >> influence of functional programming on it. I despise fp and don’t want it in >> Swift. If people want it that much use Haskell 8( >>> I might remind everyone that Discourse is open sourced and therefore tweaks >>> are possible. If you prefer a consistent font like on swift.org, than spell >>> it out and help to create a corner on the web where every Swiftier feels >>> right at home. >>> >>> >> I don’t think that Discourse is salvageable but go on. But I don’t know how >> one could rip out this big piece of JavaScript and keep ist functional. >>> Personally I’d prefer (if possible) that we’d remove profile pictures from >>> the forum and simply have only full names (colored?) + some kind of >>> annotation (e.g. Core Team, etc.). Profile pictures are only gimmicks that >>> does not contribute to anything at all. >>> >>> As Jan already said, the font (and font-size?) of the forum could match the >>> font from swift.org if possible. I wouldn’t mind and it’d make it a little >>> bit more alike. >>> >>> >> You don’t have to care for me - Swift 4 will be the deciding step if I throw >> any Swift work away and return to Objective-C. The heavy functional >> programming push since open sourcing is so annoying and made Swift imo a >> worse language. >> >> Jan >> ___ >> swift-evolution mailing list >> swift-evolut...@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > ___ > swift-evolution mailing list > swift-evolut...@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swi
Re: [swift-users] Custom operators in a framework
Facepalm! Of course!, thanks for clearing that up! I will file a bug report for the diagnostics. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 04 Feb 2017, at 02:14, Jordan Rose wrote: > > Interesting. I actually see two errors: > > /Users/jrose/Desktop/SwifterJSON/App/AppDelegate.swift:19:18: error: > ambiguous operator declarations found for operator > json["root"] &= 4 > ^ > :0: note: found this matching operator declaration > :0: note: found this matching operator declaration > /Users/jrose/Desktop/SwifterJSON/App/AppDelegate.swift:19:18: error: operator > is not a known binary operator > json["root"] &= 4 > ^ > > which actually seems correct in retrospect: '&=' is already a valid operator > in the 'Swift' library, and you're redefining it rather than just reusing > that definition. It works if I either remove your `infix operator &=` > declaration (and leave all the implementations in place), or if I change to > an operator that isn't already defined. Can you file a bug at bugs.swift.org > for the lousy diagnostics, at least? > > Jordan > > >> On Feb 3, 2017, at 11:34, Rien wrote: >> >> This is the “defining” package/module: >> >> https://github.com/Balancingrock/SwifterJSON >> >> For the consuming package simply generate a new executable and put the >> following in main.swift: >> >> >> import SwifterJSON >> >> >> // Note: Error disappears when the line below is un-commented >> >> // infix operator &= >> >> var json = VJson() >> >> json["root"] &= 4 >> >> print(json.code) >> >> >> (seems I have hit a snag with github, otherwise I would create a new repo >> for the executable… sorry for that.) >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Balancingrock >> Project: http://swiftfire.nl >> >> >> >> >> >>> On 03 Feb 2017, at 18:36, Jordan Rose wrote: >>> >>> The operator itself. If you’re not seeing that behavior, that’s a bug! Do >>> you have a small test case that reproduces it? (I guess it would take two >>> modules regardless, so either a SwiftPM package or an Xcode project would >>> do it.) >>> >>> Jordan >>> >>>> On Feb 3, 2017, at 09:34, Rien wrote: >>>> >>>> Are you referring to the definition of the operator (infix…) or the >>>> availability of the function that defines the operator? >>>> >>>> The functions are available, but I have to repeat the “infix…" everywhere >>>> I need them. >>>> >>>> I.e. I have a: >>>> >>>> infix operator &= >>>> >>>> And when I use that from another module I get “Operator is not a known >>>> binary operator” >>>> >>>> Once I repeat the "infix operator &=“ at the start of the file it works >>>> fine. >>>> >>>> Regards, >>>> Rien >>>> >>>> Site: http://balancingrock.nl >>>> Blog: http://swiftrien.blogspot.com >>>> Github: http://github.com/Balancingrock >>>> Project: http://swiftfire.nl >>>> >>>> >>>> >>>> >>>> >>>>> On 03 Feb 2017, at 18:14, Jordan Rose wrote: >>>>> >>>>> Operator declarations are actually public all the time, not internal. >>>>> That’s itself probably a bug, but not the world-limiting one you’re >>>>> concerned about. >>>>> >>>>> Jordan >>>>> >>>>> >>>>>> On Feb 3, 2017, at 01:18, Rien via swift-users >>>>>> wrote: >>>>>> >>>>>> It is possible to define custom operators in a framework, but it is not >>>>>> possible to assign access levels to them. >>>>>> >>>>>> As a consequence they are module internal and cannot be used outside the >>>>>> framework. >>>>>> >>>>>> Each project needs to redefine the custom operators in order to use them >>>>>> in that project. >>>>>> >>>>>> What is the rationale behind that? >>>>>> >>>>>> Or is it a bug? >>>>>> >>>>>> Are there other ways to accomplish this? >>>>>> >>>>>> Regards, >>>>>> Rien >>>>>> >>>>>> Site: http://balancingrock.nl >>>>>> Blog: http://swiftrien.blogspot.com >>>>>> Github: http://github.com/Balancingrock >>>>>> Project: http://swiftfire.nl >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ___ >>>>>> 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] Custom operators in a framework
This is the “defining” package/module: https://github.com/Balancingrock/SwifterJSON For the consuming package simply generate a new executable and put the following in main.swift: import SwifterJSON // Note: Error disappears when the line below is un-commented // infix operator &= var json = VJson() json["root"] &= 4 print(json.code) (seems I have hit a snag with github, otherwise I would create a new repo for the executable… sorry for that.) Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 03 Feb 2017, at 18:36, Jordan Rose wrote: > > The operator itself. If you’re not seeing that behavior, that’s a bug! Do you > have a small test case that reproduces it? (I guess it would take two modules > regardless, so either a SwiftPM package or an Xcode project would do it.) > > Jordan > >> On Feb 3, 2017, at 09:34, Rien wrote: >> >> Are you referring to the definition of the operator (infix…) or the >> availability of the function that defines the operator? >> >> The functions are available, but I have to repeat the “infix…" everywhere I >> need them. >> >> I.e. I have a: >> >> infix operator &= >> >> And when I use that from another module I get “Operator is not a known >> binary operator” >> >> Once I repeat the "infix operator &=“ at the start of the file it works fine. >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Balancingrock >> Project: http://swiftfire.nl >> >> >> >> >> >>> On 03 Feb 2017, at 18:14, Jordan Rose wrote: >>> >>> Operator declarations are actually public all the time, not internal. >>> That’s itself probably a bug, but not the world-limiting one you’re >>> concerned about. >>> >>> Jordan >>> >>> >>>> On Feb 3, 2017, at 01:18, Rien via swift-users >>>> wrote: >>>> >>>> It is possible to define custom operators in a framework, but it is not >>>> possible to assign access levels to them. >>>> >>>> As a consequence they are module internal and cannot be used outside the >>>> framework. >>>> >>>> Each project needs to redefine the custom operators in order to use them >>>> in that project. >>>> >>>> What is the rationale behind that? >>>> >>>> Or is it a bug? >>>> >>>> Are there other ways to accomplish this? >>>> >>>> Regards, >>>> Rien >>>> >>>> Site: http://balancingrock.nl >>>> Blog: http://swiftrien.blogspot.com >>>> Github: http://github.com/Balancingrock >>>> Project: http://swiftfire.nl >>>> >>>> >>>> >>>> >>>> >>>> ___ >>>> 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] Custom operators in a framework
Are you referring to the definition of the operator (infix…) or the availability of the function that defines the operator? The functions are available, but I have to repeat the “infix…" everywhere I need them. I.e. I have a: infix operator &= And when I use that from another module I get “Operator is not a known binary operator” Once I repeat the "infix operator &=“ at the start of the file it works fine. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 03 Feb 2017, at 18:14, Jordan Rose wrote: > > Operator declarations are actually public all the time, not internal. That’s > itself probably a bug, but not the world-limiting one you’re concerned about. > > Jordan > > >> On Feb 3, 2017, at 01:18, Rien via swift-users wrote: >> >> It is possible to define custom operators in a framework, but it is not >> possible to assign access levels to them. >> >> As a consequence they are module internal and cannot be used outside the >> framework. >> >> Each project needs to redefine the custom operators in order to use them in >> that project. >> >> What is the rationale behind that? >> >> Or is it a bug? >> >> Are there other ways to accomplish this? >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Balancingrock >> Project: http://swiftfire.nl >> >> >> >> >> >> ___ >> 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] Swift 101: JSON or XML?
I do not think there is a ‘best’ answer. I would go with JSON though. Apple’s JSON solution is fast, but it has some minor limitations and usability is not “up there”. Then again there are third party solutions, for example my own SwifterJSON single-class framework that you can download from github. :-) Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 03 Feb 2017, at 14:00, Roy Henderson via swift-users > wrote: > > Hi, > > I'm about to develop my first non-trivial (for me) Swift 3 app. It will > retrieve data from a web server and present it on an iOS device. > > I would welcome guidance regarding whether I should use JSON or XML to store > the data on the web server? The effort to generate either format will be > similar so my real decision driver is on the client side. Volume will > typically be 100-250 "records" per request with each record comprising 5-10 > text fields. > > I don't want to pull in any third-party components but stay entirely Apple. > > TIA, > > Roy > ___ > 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
[swift-users] Custom operators in a framework
It is possible to define custom operators in a framework, but it is not possible to assign access levels to them. As a consequence they are module internal and cannot be used outside the framework. Each project needs to redefine the custom operators in order to use them in that project. What is the rationale behind that? Or is it a bug? Are there other ways to accomplish this? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] SPM: Library dependency bug?
I have a system wrapper module/package for openSSL called COpenSsl. I have another package (called SecureSockets) that uses COpenSsl. This works fine. To create a framework, I then added a xcode project to SecureSockets and build the framework. This also works fine. Then I created an App (macOS) and imported the SecureSockets.framework. (Included the headers in a bridge file, updated the search paths) However I cannot use the SecureSockets module, whenever I try that I get an error message saying that COpenSsl is missing. The App does not need COpenSsl, other than through the wrapper/framework in SecureSockets. To work around this I created an empty library project called COpenSsl and included that framework in the App as well. This satisfies the compiler and I now have a working App. Is it a bug that COpenSsl is needed in the App? or am I doing something wrong? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] SPM: how to create cocoa xcode projects?
> On 26 Jan 2017, at 17:58, Doug Hill wrote: > > In Xcode, select menu item File>New>Project > > Select the template for macOS>Cocoa Application > > Doug Hill > Yes, but what is the best way to create a cocoa application building on a bunch of SPM packages? Rien. > >> On Jan 26, 2017, at 4:24 AM, Rien via swift-users >> wrote: >> >> Just a quick question, >> >>> swift package init —type executable >> >> creates an xcode project with a main.swift. >> >> I want to create a macOS cocoa based application. >> >> How is that best achieved? >> Or is that not supported yet? >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Balancingrock >> Project: http://swiftfire.nl >> >> >> >> >> >> ___ >> 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
[swift-users] SPM: how to create cocoa xcode projects?
Just a quick question, > swift package init —type executable creates an xcode project with a main.swift. I want to create a macOS cocoa based application. How is that best achieved? Or is that not supported yet? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] SPM: no such module - System Library Wrapper
Thanks, that was interesting. However I did not find a solution. The problem is not that my COpenSsl does not work, it does. I can compile & link SecureSockets just fine. However the (macOS cocoa) app that uses SecureSockets -even though it does not use COpenSsl- wants access to that module. And I don’t know how to provide that, nor do I know how to prevent this. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 26 Jan 2017, at 11:53, Alex Blewitt wrote: > > Have a look at BlueSockets which does the same kind of thing: > > https://github.com/IBM-Swift/BlueSocket > https://github.com/IBM-Swift/BlueSSLService > > There's a wrapper around OpenSSL as well: > > https://github.com/IBM-Swift/OpenSSL.git > > Alex > >> On 26 Jan 2017, at 09:49, Rien via swift-users wrote: >> >> I have created the following packages: >> >> 1) SwifterSockets (Swift) >> 2) COpenSsl (wrapper for system libraries) >> 3) SecureSockets (Swift, uses SwifterSockets and COpenSsl) >> >> Now I want to build a macOS app that uses SecureSockets. >> >> I have created the app in the traditional way, via Xcode. >> In this app I imported the frameworks created by SwifterSockets and >> SecureSockets. >> >> When I try to use SecureSockets I get the error “No such module COpenSsl” >> >> Any idea how I can include the system library wrapper ? >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Balancingrock >> Project: http://swiftfire.nl >> >> >> >> >> >> ___ >> 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
[swift-users] SPM: no such module - System Library Wrapper
I have created the following packages: 1) SwifterSockets (Swift) 2) COpenSsl (wrapper for system libraries) 3) SecureSockets (Swift, uses SwifterSockets and COpenSsl) Now I want to build a macOS app that uses SecureSockets. I have created the app in the traditional way, via Xcode. In this app I imported the frameworks created by SwifterSockets and SecureSockets. When I try to use SecureSockets I get the error “No such module COpenSsl” Any idea how I can include the system library wrapper ? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Casting function pointers
Thank Joe,
A first attempt was not successful, I will try again in a few days.
For now I have put in a work around where I put glue-code into the openSSL
library itself. I don’t like that solution, but it works.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
> On 25 Jan 2017, at 19:37, Joe Groff wrote:
>
>
>> On Jan 25, 2017, at 1:23 AM, Rien via swift-users
>> wrote:
>>
>> I have a case where a callback has the following signature:
>>
>> @convention(c) (_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?,
>> _ arg: UnsafeMutableRawPointer?) -> Int32
>>
>> But to install this callback I have to use a c-function with this signature:
>>
>> SSL_CTX_callback_ctrl (OpaquePointer!, Int32, (() -> Void)! )
>>
>> Is it possible to cast the first function to the second? If so, how?
>
> I think your best bet would be to write the shim closure yourself. Is `num` a
> pointer to the value you're supposed to receive from SSL_CTX_callback_ctrl?
> Is the `arg` really a function pointer? In that case, something like this
> might work:
>
> func callback(_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, _
> arg: UnsafeMutableRawPointer?) -> Int32
>
> let shimCallback: SSL_CTX_callback_ctrl = { ctx, cmd, fp in
> var cmdNum = cmd
> callback(ctx, &cmdNum, unsafeBitCast(fp, to: UnsafeMutableRawPointer?.self))
> }
>
> -Joe
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Callback in Swift
> On 25 Jan 2017, at 10:33, John Brownie wrote: > > Thanks, that does it for me, though I had to qualify the Unmanaged with a > type in the first part. > > Rien wrote: >> For the context I passed in: >> >> UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque()) >> >> And to get the context back inside the callback: >> >> let ourself = Unmanaged< … your type >> here…>.fromOpaque(arg!).takeUnretainedValue() >> >> Then “ourself” was the object normally obtained as “self”. >> > A more general question is how to learn these tricks. The worst pain I've had > in learning Swift is how to handle interactions with frameworks in other > languages, such as this one (Cocoa) or the Expat parser (C). The Swift book > doesn't even mention Unmanaged or opaque. The book on using Swift with > Objective-C mentions Unmanaged, but not opaque (apart from a couple of > references, neither of which mentions toOpaque/fromOpaque. If there were a > reference that gathered these things together in one place, it would be > easier to learn than simply thrashing around for a while and asking for help. I usually start off with using the debugger. And I like to print out pointer values a lot. Shows you how swift handles them. After that I usually know what to look for and am able to target my googling. Subscribing to lists (and scanning posts) like these (and evolution) also makes you more aware of what is going on. In isolation it is difficult to get a good feel for a language. Rien > -- > John Brownie > In Finland on furlough from SIL Papua New Guinea ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Casting function pointers
I should clarify: is it possible to cast: > @convention(c) (_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, _ > arg: UnsafeMutableRawPointer?) -> Int32 to: > (() -> Void)! ??? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 25 Jan 2017, at 10:23, Rien via swift-users wrote: > > I have a case where a callback has the following signature: > > @convention(c) (_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, _ > arg: UnsafeMutableRawPointer?) -> Int32 > > But to install this callback I have to use a c-function with this signature: > > SSL_CTX_callback_ctrl (OpaquePointer!, Int32, (() -> Void)! ) > > Is it possible to cast the first function to the second? If so, how? > > > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Balancingrock > Project: http://swiftfire.nl > > > > > > ___ > 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
[swift-users] Casting function pointers
I have a case where a callback has the following signature: @convention(c) (_ ssl: OpaquePointer?, _ num: UnsafeMutablePointer?, _ arg: UnsafeMutableRawPointer?) -> Int32 But to install this callback I have to use a c-function with this signature: SSL_CTX_callback_ctrl (OpaquePointer!, Int32, (() -> Void)! ) Is it possible to cast the first function to the second? If so, how? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] SPM: Specify search paths?
I am still running into walls with SPM. Is there a way to specify the header and library search paths when using the Swift Package Manager? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] SPM & Library with bridging header
==
This works:
==
First I need openSSL from Swift, that I have done with COpenSsl:
Package.swift:
import PackageDescription
let package = Package(
name: "COpenSsl",
pkgConfig: "openssl"
)
module.modulemap:
module COpenSsl [system] {
header "/usr/local/include/openssl/ssl.h"
header "/usr/local/include/openssl/err.h"
header "/usr/local/include/openssl/crypto.h"
header "/usr/local/include/openssl/evp.h"
header "/usr/local/include/openssl/x509v3.h"
export *
}
And then import this into Swift with:
import COpenSsl
==
This does not work
==
Package.swift for the C-glue code:
import PackageDescription
let package = Package(
name: "OpenSsl",
dependencies: [
.Package(url: "https://github.com/Swiftrien/COpenSsl";, "0.1.0")
]
)
OpenSsl.h:
(In Sources/include)
// #import "openssl/ssl.h"
// #import "openssl/x509.h"
// #import "openssl/x509v3.h"
@import COpenSsl;
void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *, int *,
void *), void *arg);
void skGeneralNamePopFree(STACK_OF(GENERAL_NAME) *san_names);
OpenSsl.c:
(In Sources)
#include "OpenSsl.h"
void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *, int *,
void *), void *arg) {
SSL_CTX_set_tlsext_servername_arg(ctx, arg);
SSL_CTX_set_tlsext_servername_callback(ctx, cb);
}
void skGeneralNamePopFree(STACK_OF(GENERAL_NAME) *san_names) {
sk_GENERAL_NAME_pop_free(san_names, GENERAL_NAME_free);
}
The @import COpenSsl; statement does not work. Nor do the normal includes.
Hence the compilation fails.
Maybe the import statement is wrong? is there another way to do this?
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 22 Jan 2017, at 06:25, Daniel Dunbar wrote:
>
> What is the glue code you need?
>
> You can define a C/Obj-C target in the same Swift package, and then use it
> from your Swift targets. See:
>
> https://github.com/apple/swift-package-manager/blob/master/Documentation/Reference.md#source-layouts
> for more information.
>
> - Daniel
>
>> On Jan 21, 2017, at 2:24 AM, Rien via swift-users
>> wrote:
>>
>> The thing I was missing is the “system module”.. found it now though ;-)
>>
>> So far so good, I want to put that little glue code I need in its own
>> module. However I cannot find how to specify the import search path.
>>
>> “swift build -I /usr/local/include/“ does not work (unknown command -I)
>>
>> And pkgConfig cannot be used on a non-system module.
>>
>> But without specifying the import search path, SPM cannot compile the c-code.
>>
>> Any suggestions?
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>>> On 20 Jan 2017, at 19:48, Rien via swift-users
>>> wrote:
>>>
>>> I may be missing something here, so please bear with me...
>>>
>>> The client of the lib only has to see the headers that describe the lib,
>>> not the headers of the files that were used to create the lib.
>>> Or are you referring to a case were the lib also exposes the headers of the
>>> libs that were used to create the lib?
>>>
>>> Additional info:
>>> In my particular case I use openSSL and have created a few Swift operations
>>> that use (wrap) openSSL. My lib does not expose openSSL to the client of
>>> the lib.
>>> I did have to create a 2 line c-function for a callback. That function is
>>> not exposed to the lib client. But this two line function is the reason for
>>> the “mixed language” target.
>>> Ideally no client should use openSSL directly, but it cannot be prevent of
>>> course that a client links its own files to openSSL using his own bridging
>>> file.
>>>
>>> Regards,
>>> Rien
>>>
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Swiftrien
>>> Project: http://swiftfire.nl
>>>
>>>
>>>
>>>
>>>> On 20 Jan 2017, at 18:39, Jordan Rose wrote:
>>>>
>>>> Hi, Rien. Libraries don’t support bridgin
Re: [swift-users] enum compare
Oh, I am not using the correct terminology, sorry. Enum’s don’t have
“instances” right?
Anyhow, I guess you get my drift…
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 21 Jan 2017, at 14:23, Rien wrote:
>
> The “==“ operation can only compare concrete instances of the enum.
> With “type == ACType.other” the right side is not an instance. as the
> associated value is missing.
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
>
>
>
>
>> On 21 Jan 2017, at 13:56, tridiak via swift-users
>> wrote:
>>
>> Been searching and trying to figure out a comparison problem.
>>
>> func ==(lhs : ACType, rhs : ACType) -> Bool {
>> switch (lhs,rhs) {
>> case (.other, .other):
>> return true
>> case (.other, _):
>> return false
>> case (_, .other):
>> return false
>> default:
>> return lhs == rhs
>> }
>> }
>>
>> enum ACType {
>> case noType
>> case natural
>> case armour
>> case shield
>> case deflection
>> case dodge
>> case sacred
>> case luck
>> case other(String)
>>
>> static func Stacks(type : ACType) -> Bool {
>> return type == ACType.noType || type == ACType.dodge || type ==
>> ACType.other
>> }
>> }
>>
>> I get an error concerning ‘type == ACType.other’.
>> Compiler blab: Binary operator '==' cannot be applied to operands of type
>> 'ACType' and '(String) -> ACType'
>>
>> How do I fix this? Simply cannot see it.
>>
>> TIA Mark
>> ___
>> 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] enum compare
The “==“ operation can only compare concrete instances of the enum.
With “type == ACType.other” the right side is not an instance. as the
associated value is missing.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 21 Jan 2017, at 13:56, tridiak via swift-users
> wrote:
>
> Been searching and trying to figure out a comparison problem.
>
> func ==(lhs : ACType, rhs : ACType) -> Bool {
> switch (lhs,rhs) {
> case (.other, .other):
> return true
> case (.other, _):
> return false
> case (_, .other):
> return false
> default:
> return lhs == rhs
> }
> }
>
> enum ACType {
> case noType
> case natural
> case armour
> case shield
> case deflection
> case dodge
> case sacred
> case luck
> case other(String)
>
> static func Stacks(type : ACType) -> Bool {
> return type == ACType.noType || type == ACType.dodge || type ==
> ACType.other
> }
> }
>
> I get an error concerning ‘type == ACType.other’.
> Compiler blab: Binary operator '==' cannot be applied to operands of type
> 'ACType' and '(String) -> ACType'
>
> How do I fix this? Simply cannot see it.
>
> TIA Mark
> ___
> 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] SPM & Library with bridging header
The thing I was missing is the “system module”.. found it now though ;-) So far so good, I want to put that little glue code I need in its own module. However I cannot find how to specify the import search path. “swift build -I /usr/local/include/“ does not work (unknown command -I) And pkgConfig cannot be used on a non-system module. But without specifying the import search path, SPM cannot compile the c-code. Any suggestions? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 20 Jan 2017, at 19:48, Rien via swift-users wrote: > > I may be missing something here, so please bear with me... > > The client of the lib only has to see the headers that describe the lib, not > the headers of the files that were used to create the lib. > Or are you referring to a case were the lib also exposes the headers of the > libs that were used to create the lib? > > Additional info: > In my particular case I use openSSL and have created a few Swift operations > that use (wrap) openSSL. My lib does not expose openSSL to the client of the > lib. > I did have to create a 2 line c-function for a callback. That function is not > exposed to the lib client. But this two line function is the reason for the > “mixed language” target. > Ideally no client should use openSSL directly, but it cannot be prevent of > course that a client links its own files to openSSL using his own bridging > file. > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Swiftrien > Project: http://swiftfire.nl > > > > >> On 20 Jan 2017, at 18:39, Jordan Rose wrote: >> >> Hi, Rien. Libraries don’t support bridging headers because the client of the >> library has to be able to import the header, and arbitrary bridging headers >> may conflict. (This is actually the primary purpose of modules for >> Objective-C: to declare a group of headers that are self-contained—besides >> what other modules they import—and can therefore be imported earlier or >> later without difficulty.) The compiler will mildly try to stop you from >> doing this if it can figure out you’re building a library, but it’s a bad >> idea no matter what. Even if everything appears to compile fine, it’s likely >> you’ll get inscrutable errors when trying te debug anything that uses your >> library. >> >> The particular difference between Xcode-created frameworks and >> SwiftPM-generated libraries is that Xcode frameworks are set up to be >> mixed-source, using the Objective-C public umbrella header in place of a >> bridging header. SwiftPM doesn’t support mixed-source targets. (Since I >> don’t work on SwiftPM myself I don’t know if there are any public plans to >> do so.) >> >> The recommended solution is to group your Objective-C headers into modules >> (usually just frameworks) and import them that way, rather than to jam them >> in via a bridging header. >> >> Sorry for the trouble, >> Jordan >> >> >>> On Jan 20, 2017, at 08:49, Rien via swift-users >>> wrote: >>> >>> I noticed something strange about Xcode and SPM concerning the capability >>> to generate Libraries. >>> >>> When I try to create a Library in Xcode and then want to add an Objective-C >>> bridging header, that is denied. It claims that bridging is not supported >>> for Libraries. >>> >>> When I create an Xcode project through the SPM (with “swift package >>> generate-xcodeproj”) then I can use bridging headers, even though the end >>> result is a library. >>> >>> Question: Is this a viable work around? or are there hidden dangers that >>> might not be immediately apparent? >>> >>> As a side note: SPM complains about multiple languages and currently only >>> supports pure Swift modules. >>> This creates the strange situation that I now use SPM to create an xcode >>> project and then use Xcode to create bridged mixed language libraries. >>> >>> Regards, >>> Rien >>> >>> Site: http://balancingrock.nl >>> Blog: http://swiftrien.blogspot.com >>> Github: http://github.com/Swiftrien >>> Project: http://swiftfire.nl >>> >>> >>> >>> >>> ___ >>> 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 ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] SPM & Library with bridging header
I may be missing something here, so please bear with me... The client of the lib only has to see the headers that describe the lib, not the headers of the files that were used to create the lib. Or are you referring to a case were the lib also exposes the headers of the libs that were used to create the lib? Additional info: In my particular case I use openSSL and have created a few Swift operations that use (wrap) openSSL. My lib does not expose openSSL to the client of the lib. I did have to create a 2 line c-function for a callback. That function is not exposed to the lib client. But this two line function is the reason for the “mixed language” target. Ideally no client should use openSSL directly, but it cannot be prevent of course that a client links its own files to openSSL using his own bridging file. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 20 Jan 2017, at 18:39, Jordan Rose wrote: > > Hi, Rien. Libraries don’t support bridging headers because the client of the > library has to be able to import the header, and arbitrary bridging headers > may conflict. (This is actually the primary purpose of modules for > Objective-C: to declare a group of headers that are self-contained—besides > what other modules they import—and can therefore be imported earlier or later > without difficulty.) The compiler will mildly try to stop you from doing this > if it can figure out you’re building a library, but it’s a bad idea no matter > what. Even if everything appears to compile fine, it’s likely you’ll get > inscrutable errors when trying te debug anything that uses your library. > > The particular difference between Xcode-created frameworks and > SwiftPM-generated libraries is that Xcode frameworks are set up to be > mixed-source, using the Objective-C public umbrella header in place of a > bridging header. SwiftPM doesn’t support mixed-source targets. (Since I don’t > work on SwiftPM myself I don’t know if there are any public plans to do so.) > > The recommended solution is to group your Objective-C headers into modules > (usually just frameworks) and import them that way, rather than to jam them > in via a bridging header. > > Sorry for the trouble, > Jordan > > >> On Jan 20, 2017, at 08:49, Rien via swift-users >> wrote: >> >> I noticed something strange about Xcode and SPM concerning the capability to >> generate Libraries. >> >> When I try to create a Library in Xcode and then want to add an Objective-C >> bridging header, that is denied. It claims that bridging is not supported >> for Libraries. >> >> When I create an Xcode project through the SPM (with “swift package >> generate-xcodeproj”) then I can use bridging headers, even though the end >> result is a library. >> >> Question: Is this a viable work around? or are there hidden dangers that >> might not be immediately apparent? >> >> As a side note: SPM complains about multiple languages and currently only >> supports pure Swift modules. >> This creates the strange situation that I now use SPM to create an xcode >> project and then use Xcode to create bridged mixed language libraries. >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Swiftrien >> Project: http://swiftfire.nl >> >> >> >> >> ___ >> 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
[swift-users] SPM & Library with bridging header
I noticed something strange about Xcode and SPM concerning the capability to generate Libraries. When I try to create a Library in Xcode and then want to add an Objective-C bridging header, that is denied. It claims that bridging is not supported for Libraries. When I create an Xcode project through the SPM (with “swift package generate-xcodeproj”) then I can use bridging headers, even though the end result is a library. Question: Is this a viable work around? or are there hidden dangers that might not be immediately apparent? As a side note: SPM complains about multiple languages and currently only supports pure Swift modules. This creates the strange situation that I now use SPM to create an xcode project and then use Xcode to create bridged mixed language libraries. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Exclamation mark's in swift parameter listings?
Thanks Slava, Then my memory wasn’t that bad. This is indeed what I was thinking of, but I should not have referred to it as ‘boxing’ ? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 19 Jan 2017, at 05:57, Slava Pestov wrote: > > For what it’s worth, if T is a reference type or Unsafe*Pointer, then T and > Optional have the same exact representation in memory. > > The compiler is smart enough to know that a non-optional pointer can never be > NULL, so a NULL value of the underlying type can be used to unambiguously > encode the ‘none’ case. This is not the case with Optional for > example, where every bit pattern represents a potentially valid NSRect value, > so Optional has to add an extra tag byte to distinguish the two enum > cases from each other. > > Slava > >> On Jan 10, 2017, at 9:52 AM, Rien via swift-users >> wrote: >> >> I stand corrected. >> >> I do/did think that there is a difference in the way it handles pointers >> optionals and other optionals, but I now realise that even that could not be >> the case. >> So please ignore the last line in my previous post. >> >> The rest still stand ;-) >> >> Regards, >> Rien >> >> Site: http://balancingrock.nl >> Blog: http://swiftrien.blogspot.com >> Github: http://github.com/Swiftrien >> Project: http://swiftfire.nl >> >> >> >> >>> On 10 Jan 2017, at 18:14, Joe Groff wrote: >>> >>> >>>> On Jan 9, 2017, at 11:19 PM, Rien via swift-users >>>> wrote: >>>> >>>> It means that a call to that function with an optional will unwrap the >>>> optional before it is used. >>>> >>>> That is quite neat when dealing with C-API’s because often you will >>>> receive a pointer from a C-function which is optional to account for the >>>> fact that it can be NULL (= nil). >>>> By using a forced unwrapped input parameter you are saved the trouble of >>>> unwrapping all these pointers when using them as input for other C-APIs. >>>> >>>> In short, it makes it easier to interface with C-API’s. >>>> >>>> Note that there is some under-the-hood magic going on because a C-pointer >>>> is an unboxed value, while a ‘normal’ optional is a boxed value. >>> >>> Optionals are never boxed. >>> >>> -Joe >> >> ___ >> 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
[swift-users] Migrating to SPM, best practise?
I have a small sockets based framework on Github (SwifterSockets). It was created before SPM existed. The next update is planned, and I want to move to SPM. 1) How to create a package around the old xcode project? 2) I am unsure how to move from the old git structure to the new. What would be the best/easiest way to achieve this? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] C-function not found by linker
Sometimes you just have to post a stupid question to see what you did wrong :-(
So please disregard….
PS: it was of course the “static” (I have no clue why I did put that in there…
oh well)
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 11 Jan 2017, at 10:28, Rien via swift-users wrote:
>
> My project uses openSSL and that works fine.
>
> I needed one specific function that cannot be accessed from Swift directly,
> so I created a C-file for that. (both .h and .c file)
>
> The function is found during compilation.
>
> But is then reported as “unused” and the linker reports “missing function”.
>
> Any idea’s how this can be caused?
>
> More info:
>
> The .h file:
>
> static void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *,
> int *, void *), void *arg);
>
> The .c file:
>
> static void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *,
> int *, void *), void *arg) {
>SSL_CTX_set_tlsext_servername_arg(ctx, arg);
>SSL_CTX_set_tlsext_servername_callback(ctx, cb);
> }
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
>
>
>
>
> ___
> 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
[swift-users] C-function not found by linker
My project uses openSSL and that works fine.
I needed one specific function that cannot be accessed from Swift directly, so
I created a C-file for that. (both .h and .c file)
The function is found during compilation.
But is then reported as “unused” and the linker reports “missing function”.
Any idea’s how this can be caused?
More info:
The .h file:
static void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *,
int *, void *), void *arg);
The .c file:
static void sslCtxSetTlsExtServernameCallback(SSL_CTX *ctx, int (*cb)(SSL *,
int *, void *), void *arg) {
SSL_CTX_set_tlsext_servername_arg(ctx, arg);
SSL_CTX_set_tlsext_servername_callback(ctx, cb);
}
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Exclamation mark's in swift parameter listings?
I stand corrected. I do/did think that there is a difference in the way it handles pointers optionals and other optionals, but I now realise that even that could not be the case. So please ignore the last line in my previous post. The rest still stand ;-) Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 10 Jan 2017, at 18:14, Joe Groff wrote: > > >> On Jan 9, 2017, at 11:19 PM, Rien via swift-users >> wrote: >> >> It means that a call to that function with an optional will unwrap the >> optional before it is used. >> >> That is quite neat when dealing with C-API’s because often you will receive >> a pointer from a C-function which is optional to account for the fact that >> it can be NULL (= nil). >> By using a forced unwrapped input parameter you are saved the trouble of >> unwrapping all these pointers when using them as input for other C-APIs. >> >> In short, it makes it easier to interface with C-API’s. >> >> Note that there is some under-the-hood magic going on because a C-pointer is >> an unboxed value, while a ‘normal’ optional is a boxed value. > > Optionals are never boxed. > > -Joe ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Exclamation mark's in swift parameter listings?
It means that a call to that function with an optional will unwrap the optional
before it is used.
That is quite neat when dealing with C-API’s because often you will receive a
pointer from a C-function which is optional to account for the fact that it can
be NULL (= nil).
By using a forced unwrapped input parameter you are saved the trouble of
unwrapping all these pointers when using them as input for other C-APIs.
In short, it makes it easier to interface with C-API’s.
Note that there is some under-the-hood magic going on because a C-pointer is an
unboxed value, while a ‘normal’ optional is a boxed value.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 10 Jan 2017, at 01:23, Ethin Probst via swift-users
> wrote:
>
> Hello all,
> I was wondering what an exclamation mark in a swift parameter listing
> means. For instance, I used Elements Oxidizer Live to translate some
> C# code into Swift. Reviewing it, I found the following (among
> others):
> @DllImport("ScriptHookV.dll")
> private static __extern func scriptRegister(_ module: System.IntPtr!,
> _ LP_SCRIPT_MAIN: LP_SCRIPT_MAINDelegate!)
> What I'm wondering is what does the '!' in that list of parameters
> mean? I also saw it when writing another program:
>func MainForm_Load(_ sender: System.Object!, _ e: System.EventArgs!) {
> // ...
> }
> I don't recall the swift book teaching you what that means, so could
> someone tell me what those mean?
> --
> Signed,
> Ethin D. Probst
> ___
> 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] getResourceValue
Thanks Rod, very enlightening!
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 06 Jan 2017, at 15:19, Rod Brown wrote:
>
>
>> On 7 Jan 2017, at 12:50 am, Rien wrote:
>>
>> Hmm, that is interesting to know. I had not realised that URL is in fact NOT
>> a NSURL but a new type that is based on NSURL (and can be toll-free bridged
>> I assume?).
>
> URL a new Type, which internally wraps a NSURL reference. It is practically
> toll free bridged, as URL is simply a struct wrapper placed around the
> internal reference.
>
> NSURL is a class and has reference semantics. That is, if you change the URL,
> it would change all URLs with the same reference. This is why NSURL doesn’t
> allow mutation. If you look at the NSURL API, it has a lot of methods like
> “URLByAppendingPathComponent” which import into Swift 3 as
> “appendingPathComponent()”. These return *copies* of the NSURL reference,
> with the applied mutation.
>
> URL is a struct and has value semantics. That is, if you change the URL, it
> only changes the struct at this place and has no wider effects. Thus, there
> are new mutating methods on this struct, love “appendPathExtension()” and
> “appendPathComponent()” that allow mutation, because it only affects this
> local copy. These methods internally actually use the
> appendingPathComponent() method to get a replacement NSURL instance internal
> of the struct.
>
> The URL struct mutating behaviour makes URL manipulation much more convenient
> in Swift 3.
>
>> I also presume that the same is true for Data/NSData, Date/NSDate etc?
>
> Correct. Except Date/NSDate is actually a slight edge case.
>
> Instead of Date simply wrapping an NSDate, it actually only wraps the
> NSDate’s timeIntervalSinceReferenceDate. This is because there’s no point
> wrapping the internal reference to the NSDate, it’s more performant simply to
> wrap the NSTimeInterval (a Double) and get true struct properties. You should
> note that this means when you cast from Date to NSDate, you need to create a
> new reference each time.
>
> This becomes a bigger issue for IndexPath/NSIndexPath which also does this.
> Casting between NSIndexPath and IndexPath can be somewhat less performant, as
> it can hold an arbitrarily large number of integers. It’s also interesting to
> note that NSIndexPath has an optimisations that could make it perform better
> than IndexPath: NSIndexPath uses tagged pointers for row/item and section
> conveniences on iOS, and IndexPath does not. This should really not concern
> you generally, but you should avoid casting backwards and forwards between
> the Struct and Reference types a lot as this could cause unnecessary
> performance problems.
>
> If you want to see the struct overlay for Foundation for yourself, take a
> look here:
> https://github.com/apple/swift/tree/master/stdlib/public/SDK/Foundation
>
>>
>> (Failure on my part, as I did of course know that the .path method/var is in
>> fact different on URL and NSURL)
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>>> On 06 Jan 2017, at 14:39, Rod Brown via swift-users
>>> wrote:
>>>
>>> Hi Jan,
>>>
>>> The Swift 3 URL struct has a modernized version of the NSURL API which
>>> works far better in Swift. This replaces “getResourceValue(…)” with the API
>>> you mentioned: “resourceValues(forKeys:)”.
>>>
>>>
>>> Previously, in Swift 2, you had to use an separate value, use
>>> AutoreleasingUnsafeMutablePointers, conditionally cast and then hope you
>>> got the value, and that you used the correct typecast for the key you were
>>> asking for:
>>>
>>> let url = NSURL(fileURLWithPath: "/Users/me/Desktop/File.png")
>>>
>>> var fileType: AnyObject? = nil
>>> do {
>>>try url.getResourceValue(&fileType, forKey: NSURLTypeIdentifierKey)
>>>
>>>if let type = fileType as? String {
>>>// Use the file type here
>>>} else {
>>>// Handle error
>>>}
>>> } catch {
>>>// Handle error
>>> }
>>>
>>>
>>> In Swift 3 with the new Swift URL, the resourceValues(forKeys:) creates a
>>> struct with optional type safe properties representing each resource key
>>> type, and returns it, allowing you to use if let syntax:
>>>
>>> let url = URL(fileURLWithPath: "/Users/me/Desktop/File.png")
>>> if let resourceValues = try? url.resourceValues(forKeys:
>>> [.typeIdentifierKey]),
>>> let fileType = resourceValues.typeIdentifier {
>>> // Use the file type here
>>> }
>>>
>>>
>>> This is a much cleaner, clearer, and type-safe API.
>>>
>>> If you want to use the old API, you can simply cast back to NSURL if you
>>> require the old behaviour. That said, the new one should serve all your
>>> needs and make things so much easier so I recommend you g
Re: [swift-users] getResourceValue
Hmm, that is interesting to know. I had not realised that URL is in fact NOT a
NSURL but a new type that is based on NSURL (and can be toll-free bridged I
assume?).
I also presume that the same is true for Data/NSData, Date/NSDate etc?
(Failure on my part, as I did of course know that the .path method/var is in
fact different on URL and NSURL)
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 06 Jan 2017, at 14:39, Rod Brown via swift-users
> wrote:
>
> Hi Jan,
>
> The Swift 3 URL struct has a modernized version of the NSURL API which works
> far better in Swift. This replaces “getResourceValue(…)” with the API you
> mentioned: “resourceValues(forKeys:)”.
>
>
> Previously, in Swift 2, you had to use an separate value, use
> AutoreleasingUnsafeMutablePointers, conditionally cast and then hope you got
> the value, and that you used the correct typecast for the key you were asking
> for:
>
> let url = NSURL(fileURLWithPath: "/Users/me/Desktop/File.png")
>
> var fileType: AnyObject? = nil
> do {
> try url.getResourceValue(&fileType, forKey: NSURLTypeIdentifierKey)
>
> if let type = fileType as? String {
> // Use the file type here
> } else {
> // Handle error
> }
> } catch {
> // Handle error
> }
>
>
> In Swift 3 with the new Swift URL, the resourceValues(forKeys:) creates a
> struct with optional type safe properties representing each resource key
> type, and returns it, allowing you to use if let syntax:
>
> let url = URL(fileURLWithPath: "/Users/me/Desktop/File.png")
> if let resourceValues = try? url.resourceValues(forKeys:
> [.typeIdentifierKey]),
>let fileType = resourceValues.typeIdentifier {
>// Use the file type here
> }
>
>
> This is a much cleaner, clearer, and type-safe API.
>
> If you want to use the old API, you can simply cast back to NSURL if you
> require the old behaviour. That said, the new one should serve all your needs
> and make things so much easier so I recommend you give it a go.
>
> Hope this helps,
>
> Rod
>
>
>
>
>> On 6 Jan 2017, at 6:36 am, J.E. Schotsman via swift-users
>> wrote:
>>
>> Hello,
>>
>> Is getResourceValue a method or URL or only on NSURL?
>> After migrating a project to Swift 3 I have code like
>>
>> var file:URL
>> file.getResourceValue(...) // compiles!
>>
>> From the documentation and the headers I get the impression that this should
>> not compile!
>>
>> TIA,
>>
>> Jan E.
>> ___
>> 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
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] getResourceValue
URL is the same as NSURL in Swift 3 Foundation -> NSURL -> getResourceValue. If you use xcode, open up the Help -> Documentation and API reference The do a search for getResourceValue. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 06 Jan 2017, at 10:01, J.E. Schotsman via swift-users > wrote: > > >> On 06 Jan 2017, at 08:25, Rien wrote: >> >> What is your real question? >> Obviously the doc says that this is fine, so what are you asking? what is >> your problem? > > Which doc? > My doc is the Xcode 8.2.1 documentation for URL, which only has the methods > > resourceValues(forKeys: Set) > > and > > setResourceValues(URLResourceValues) > >>> On 05 Jan 2017, at 20:36, J.E. Schotsman via swift-users >>> wrote: >>> >>> Hello, >>> >>> Is getResourceValue a method or URL or only on NSURL? >>> After migrating a project to Swift 3 I have code like >>> >>> var file:URL >>> file.getResourceValue(...) // compiles! >>> >>> From the documentation and the headers I get the impression that this >>> should not compile! > ___ > 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] getResourceValue
What is your real question? Obviously the doc says that this is fine, so what are you asking? what is your problem? Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 05 Jan 2017, at 20:36, J.E. Schotsman via swift-users > wrote: > > Hello, > > Is getResourceValue a method or URL or only on NSURL? > After migrating a project to Swift 3 I have code like > > var file:URL > file.getResourceValue(...) // compiles! > > From the documentation and the headers I get the impression that this should > not compile! > > TIA, > > Jan E. > ___ > 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] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them
As you know. there is no ambiguity, no warnings needed.
(The parameter is part of the identifier of the function)
Imo, this request falls into the category “do as I think, not as I say”.
That is a discussion without end. Personally I am against ANY warnings of this
kind. The reason is that I want my code to compile warnings free (default
compiler behaviour) and I do not want an extra pragma in the code to instruct
the compiler that when I am calling “foo()” I do indeed want to call “foo()”.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users
> wrote:
>
> Hello,
>
> I wasn’t sure whether to post this message here, at swift-dev, or at
> swift-evolution. so I’ll try here first. Hopefully it will get to the right
> group of people or, if not, someone will point me to the right mailing list.
>
> I came across a situation that boils down to this example:
>
> class Parent {
>func foo() {
>print("Parent foo() called")
>}
> }
>
> class Child: Parent {
>func foo(x: Int = 0) {
>print("Child foo() called")
>}
> }
>
> let c = Child()
> c.foo() // prints "Parent foo() called"
>
> I understand why this behaves like so, namely, the subclass has a method
> foo(x:) but no direct implementation of foo() so the parent’s implementation
> is invoked rather than the child's. That’s all fine except that it is not
> very intuitive.
>
> I would argue that the expectation is that the search for an implementation
> should start with the subclass (which is does) but should look at all
> possible restrictions of parent implementations, including the restriction
> due to default values.
>
> At the very least, I think the compiler should emit a warning or possibly
> even an error.
>
> Thanks for reading.
> Cheers,
>
> Wagner
> ___
> 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] UnsafePointer and C-String
Thanks Jeremy & Ole,
That was indeed my expectation, but I had not thought of looking in the source
code!
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 03 Jan 2017, at 16:31, Ole Begemann wrote:
>
>> What I cannot find though is the guarantee that the buffer where the
>> String is converted to an UTF8 sequence is always null-terminated.
>>
>> I very much suspect it is, and all my tests did find a null-terminated
>> string.
>>
>> Question: Does anybody know for sure that the buffer is always
>> null-terminated? (a link to where I can check this would be most
>> appreciated)
>
> I'm not 100% certain, but I think the compiler uses this function to convert
> a String argument to a pointer:
>
> /// Derive a UTF-8 pointer argument from a value string parameter.
> public // COMPILER_INTRINSIC
> func _convertConstStringToUTF8PointerArgument<
> ToPointer : _Pointer
> >(_ str: String) -> (AnyObject?, ToPointer) {
> let utf8 = Array(str.utf8CString)
> return _convertConstArrayToPointerArgument(utf8)
> }
>
> Source: Pointer.swift [1]
>
> This in turn calls `String.utf8CString` [2], which indeed returns a
> null-terminated string.
>
> [1]:
> https://github.com/apple/swift/blob/master/stdlib/public/core/Pointer.swift#L85-L92
> [2]:
> https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF8.swift#L383-L405
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] UnsafePointer and C-String
The documentation at https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html shows that it is possible to use String where an UnsafePointer is needed. API calls to C that need a char* are translated to UnsafePointer. It follows that we can use a String where a char* is needed. However in C a string is not only a char*, it is also null-terminated. What I cannot find though is the guarantee that the buffer where the String is converted to an UTF8 sequence is always null-terminated. I very much suspect it is, and all my tests did find a null-terminated string. Question: Does anybody know for sure that the buffer is always null-terminated? (a link to where I can check this would be most appreciated) Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Weird protocol behaviour.
> On 30 Dec 2016, at 17:26, Mikhail Seriukov wrote:
>
> So as the foo(_ x:A) function is generic, when we call foo(x) compiler
> needs to determine what type is A to be able to create concrete function. But
> x defined as let x = X() as P so we only know about it that it conforms to P
> but not its real type to put instead of A. Right?
I believe so.
> But where is the "Protocols do not conform to themselves" limitation is
> coming out?
I think it was a reference to earlier in the discussion where a protocol was
passed as a parameter.
Rien.
>
> 2016-12-30 18:25 GMT+07:00 Rien :
>
> > On 30 Dec 2016, at 12:14, Mikhail Seriukov via swift-users
> > wrote:
> >
> > Ok,
> > But I think I still do not get it.
> > What does really happen when we write this?
> >> let x = X() as P
> >>
>
> 'X()' creates a value.
> 'as P’ constrains the value such that the only things we know about it is
> that the value will conform to the protocol P
> ‘let x =‘ assigns the value to a constant, and the only thing we know about
> that constant is that we can call an operation of protocol P on it.
>
> Rien.
>
> > As I said, I expect x to be Any after that. If it is, then it should be
> > ok IMO.
> > But if it is not then what is the actual type of x?
> >
> > So the real question is how the type checker works here?
> >
> >
> > 2016-12-25 22:13 GMT+07:00 Slava Pestov :
> >
> >> On Dec 22, 2016, at 4:43 PM, Howard Lovatt via swift-users
> >> wrote:
> >>
> >> The following variation works:
> >>
> >> protocol P {}
> >>
> >> class P1:P {}
> >>
> >> class X:P1 {}
> >>
> >> func foo(_ x:A) {}
> >>
> >> func bar() {
> >> //let x = X() // this compiles
> >> let x = X() as P1 // this does not compile. Why?
> >> foo(x)
> >> }
> >>
> >> Which adds credence to the bug theory.
> >
> > It’s an intentional limitation. Protocols do not conform to themselves.
> > Lifting the restriction would be difficult to do efficiently given our
> > representation of generics and protocols at runtime.
> >
> > Slava
> >
> >>
> >> Note two changes: 1. two levels of inheritance and 2. change to classes.
> >> If you do two levels using protocols it doesn't work if you use either
> >> classes or structs.
> >>
> >>
> >> -- Howard.
> >>
> >> On 23 December 2016 at 07:29, Kevin Nattinger wrote:
> >> I recall seeing a request on the -evolution list for something like `T :=
> >> X` to indicate it could be X itself or anything inheriting / implementing
> >> it, so it’s certainly known behavior, if not desired. IMO it’s a bug and
> >> `:` should be fixed to include the root type, whether or not that requires
> >> a discussion on -evolution.
> >>
> >>> On Dec 22, 2016, at 2:17 PM, Howard Lovatt via swift-users
> >>> wrote:
> >>>
> >>> I suspect a compiler bug since A is a P. The equivalent in Java works:
> >>>
> >>> interface P {}
> >>> class X implements P {}
> >>>
> >>> void foo(A x) {}
> >>>
> >>> void bar() {
> >>> final P x = new X();
> >>> foo(x);
> >>> }
> >>>
> >>> -- Howard.
> >>>
> >>> On 23 Dec 2016, at 3:19 am, Rien via swift-users
> >>> wrote:
> >>>
> >>>> IMO the error message says it all:
> >>>>
> >>>> Playground execution failed: error: MyPlayground8.playground:9:5: error:
> >>>> cannot invoke 'foo' with an argument list of type '(P)'
> >>>>foo(x)
> >>>>^
> >>>>
> >>>> MyPlayground8.playground:9:5: note: expected an argument list of type
> >>>> '(A)'
> >>>>foo(x)
> >>>>^
> >>>>
> >>>> I.e. you are passing in a protocol while the function is specified for a
> >>>> type.
> >>>> Said other way: On which data do you expect the protocol to operate?
> >>>>
> >>>> Regards,
> >>>> Rien
> >>>>
> >>>> Site: http://balancingrock.nl
> >>>> Blog: http://swiftrien.blogspot.com
> >>>> Github: http://github.com/Swiftrien
> >>>> Project: http://swift
Re: [swift-users] Weird protocol behaviour.
> On 30 Dec 2016, at 12:14, Mikhail Seriukov via swift-users
> wrote:
>
> Ok,
> But I think I still do not get it.
> What does really happen when we write this?
>> let x = X() as P
>>
'X()' creates a value.
'as P’ constrains the value such that the only things we know about it is that
the value will conform to the protocol P
‘let x =‘ assigns the value to a constant, and the only thing we know about
that constant is that we can call an operation of protocol P on it.
Rien.
> As I said, I expect x to be Any after that. If it is, then it should be ok
> IMO.
> But if it is not then what is the actual type of x?
>
> So the real question is how the type checker works here?
>
>
> 2016-12-25 22:13 GMT+07:00 Slava Pestov :
>
>> On Dec 22, 2016, at 4:43 PM, Howard Lovatt via swift-users
>> wrote:
>>
>> The following variation works:
>>
>> protocol P {}
>>
>> class P1:P {}
>>
>> class X:P1 {}
>>
>> func foo(_ x:A) {}
>>
>> func bar() {
>> //let x = X() // this compiles
>> let x = X() as P1 // this does not compile. Why?
>> foo(x)
>> }
>>
>> Which adds credence to the bug theory.
>
> It’s an intentional limitation. Protocols do not conform to themselves.
> Lifting the restriction would be difficult to do efficiently given our
> representation of generics and protocols at runtime.
>
> Slava
>
>>
>> Note two changes: 1. two levels of inheritance and 2. change to classes. If
>> you do two levels using protocols it doesn't work if you use either classes
>> or structs.
>>
>>
>> -- Howard.
>>
>> On 23 December 2016 at 07:29, Kevin Nattinger wrote:
>> I recall seeing a request on the -evolution list for something like `T := X`
>> to indicate it could be X itself or anything inheriting / implementing it,
>> so it’s certainly known behavior, if not desired. IMO it’s a bug and `:`
>> should be fixed to include the root type, whether or not that requires a
>> discussion on -evolution.
>>
>>> On Dec 22, 2016, at 2:17 PM, Howard Lovatt via swift-users
>>> wrote:
>>>
>>> I suspect a compiler bug since A is a P. The equivalent in Java works:
>>>
>>> interface P {}
>>> class X implements P {}
>>>
>>> void foo(A x) {}
>>>
>>> void bar() {
>>> final P x = new X();
>>> foo(x);
>>> }
>>>
>>> -- Howard.
>>>
>>> On 23 Dec 2016, at 3:19 am, Rien via swift-users
>>> wrote:
>>>
>>>> IMO the error message says it all:
>>>>
>>>> Playground execution failed: error: MyPlayground8.playground:9:5: error:
>>>> cannot invoke 'foo' with an argument list of type '(P)'
>>>>foo(x)
>>>>^
>>>>
>>>> MyPlayground8.playground:9:5: note: expected an argument list of type '(A)'
>>>>foo(x)
>>>>^
>>>>
>>>> I.e. you are passing in a protocol while the function is specified for a
>>>> type.
>>>> Said other way: On which data do you expect the protocol to operate?
>>>>
>>>> Regards,
>>>> Rien
>>>>
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Swiftrien
>>>> Project: http://swiftfire.nl
>>>>
>>>>
>>>>
>>>>
>>>>> On 22 Dec 2016, at 17:05, Mikhail Seriukov via swift-users
>>>>> wrote:
>>>>>
>>>>> Hello community! I' wondering if somebody can explain this to me.
>>>>> Please take look at the snippet.
>>>>>
>>>>> protocol P {}
>>>>> struct X:P {}
>>>>>
>>>>> func foo(_ x:A) {}
>>>>>
>>>>> func bar() {
>>>>>//let x = X() // this compiles
>>>>>let x = X() as P // this does not compile. Why?
>>>>>foo(x)
>>>>> }
>>>>>
>>>>> I expect the both cases to work though. But only first works? And I do
>>>>> not understand why.
>>>>> My coworkers said that it is a compiler bug, but I'm not shure it is.
>>>>> Thanks for the help.
>>>>> ___
>>>>> 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
>>> ___
>>> 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
>
>
> ___
> 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] How much memory does withMemoryRebound bind
Ah, ok.
In that case, I believe it is correct because sockaddr_storage is in fact big
enough to hold either the IPv4 or IPv6 structure.
When bits go unused, that causes no harm. And when “addr” goes out of scope, it
will be completely deallocated, so no memory leak either.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 29 Dec 2016, at 15:52, Etan Kissling wrote:
>
> I meant the question in a more generalized sense.
> The sockaddr example is just one that is easily understandable :-)
>
> Thanks for the link though, interesting read!
>
>> On 29 Dec 2016, at 14:47, Rien wrote:
>>
>> I used the code from
>> http://blog.obdev.at/representing-socket-addresses-in-swift-using-enums/ in
>> my package SwifterSockets (see github link below)
>>
>> It does not answer your question exactly, but I think it is a rather better
>> approach to sockaddr usage.
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>>> On 29 Dec 2016, at 14:27, Etan Kissling via swift-users
>>> wrote:
>>>
>>> Hi,
>>>
>>> When calling POSIX accept, the common way is to
>>> sockaddr_storage addr = {0};
>>> sockaddr_len addrlen = 0;
>>> int clientFd = accept(serverFd, (sockaddr *) &addr, &addrlen);
>>>
>>> In Swift, this translates to
>>> var addr = sockaddr_storage()
>>> var addrlen = sockaddr_len(0)
>>> int clientFd = withUnsafeMutablePointer(to: addr) {
>>> $0.withMemoryRebound(to: sockaddr.self, capacity: 1) { addr in
>>> Foundation.accept(socket, addr, &addrlen)
>>> }
>>> }
>>>
>>> Since sockaddr is smaller than sockaddr_storage, I wonder if this is
>>> correct.
>>>
>>> If withMemoryRebound would be the same as the simple C cast, it would be
>>> okay.
>>> However, since it also requires passing the capacity, I wonder if there may
>>> be cases
>>> where it actually copies out the memory region, which could lead to memory
>>> corruption.
>>>
>>> ==> How can I guarantee that withMemoryRebound binds the complete
>>> sockaddr_storage,
>>> and prevent cases where only the first MemoryLayout.size
>>> bytes are bound?
>>>
>>> Thanks
>>>
>>> Etan
>>> ___
>>> 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] How much memory does withMemoryRebound bind
I used the code from
http://blog.obdev.at/representing-socket-addresses-in-swift-using-enums/ in my
package SwifterSockets (see github link below)
It does not answer your question exactly, but I think it is a rather better
approach to sockaddr usage.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 29 Dec 2016, at 14:27, Etan Kissling via swift-users
> wrote:
>
> Hi,
>
> When calling POSIX accept, the common way is to
> sockaddr_storage addr = {0};
> sockaddr_len addrlen = 0;
> int clientFd = accept(serverFd, (sockaddr *) &addr, &addrlen);
>
> In Swift, this translates to
> var addr = sockaddr_storage()
> var addrlen = sockaddr_len(0)
> int clientFd = withUnsafeMutablePointer(to: addr) {
>$0.withMemoryRebound(to: sockaddr.self, capacity: 1) { addr in
>Foundation.accept(socket, addr, &addrlen)
>}
> }
>
> Since sockaddr is smaller than sockaddr_storage, I wonder if this is correct.
>
> If withMemoryRebound would be the same as the simple C cast, it would be okay.
> However, since it also requires passing the capacity, I wonder if there may
> be cases
> where it actually copies out the memory region, which could lead to memory
> corruption.
>
> ==> How can I guarantee that withMemoryRebound binds the complete
> sockaddr_storage,
> and prevent cases where only the first MemoryLayout.size
> bytes are bound?
>
> Thanks
>
> Etan
> ___
> 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] Using 'SomeProtocol' as a concrete type conforming to protocol 'SomeProtocol' is not supported
As to the why question: (just guessing here)
By the time the compiler want to know what type will be in the array, it cannot
do so. The enum is a generic and thus without full type information (it only
has partial type information).
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 29 Dec 2016, at 00:41, Brandon Knope via swift-users
> wrote:
>
> I don’t understand why this is a problem
>
> protocol Element {
>
> }
>
> enum ElementNode {
> case element(T)
> case empty
> }
>
> var childElements = [ElementNode]()
>
> I need to represent an array of my nodes that could be multiple kinds of
> elements
>
> Is there a workaround?
>
> Brandon
> ___
> 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] Using 'SomeProtocol' as a concrete type conforming to protocol 'SomeProtocol' is not supported
I think you made your type (enum) unnecessary complex, the following works:
protocol Element {
}
enum ElementNode {
case element(Element)
case empty
}
var childElements = [ElementNode]()
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 29 Dec 2016, at 00:41, Brandon Knope via swift-users
> wrote:
>
> I don’t understand why this is a problem
>
> protocol Element {
>
> }
>
> enum ElementNode {
> case element(T)
> case empty
> }
>
> var childElements = [ElementNode]()
>
> I need to represent an array of my nodes that could be multiple kinds of
> elements
>
> Is there a workaround?
>
> Brandon
> ___
> 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] Weird protocol behaviour.
Sorry, should have taken the comments out of the example, they obviously have
no meaning anymore.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 23 Dec 2016, at 10:03, Rien wrote:
>
>
>> On 23 Dec 2016, at 09:43, Mikhail Seriukov wrote:
>>
>> No it does not.
>> You have made a type out of the parameter. It’s no longer a protocol.
>> IMO the failure here is to understand the difference between a type and a
>> protocol.
>> A type (even if empty) is always a combination of storage with functions
>> (that are assumed to work on the data in storage)
>> A protocol is just a definition of functions without the accompanying data.
>>
>> I see your point.
>> But actually when I write it as `let x = X() as P` I really mean that I
>> want `x` to be `AnyObject` but conforming to P, not just protocol itself.
>> Is it even possible to downcast it this way?
>
> Yes, but only for a destination that needs a protocol. Not for a destination
> that needs a type.
>
> I.e. in the example
>
> protocol P {}
> struct X:P {}
>
> func foo(_ x:A) {}
>
> func bar(_ x:P) {}
>
> func bar() {
>var p: P
>//let x = X() // this compiles
>let x = X() as P // this does not compile. Why?
>p = x
>bar(p)
> }
>
> Regards,
> Rien.
>
>>
>> 2016-12-23 14:51 GMT+07:00 Marinus van der Lugt :
>>
>>> On 22 Dec 2016, at 22:43, Howard Lovatt wrote:
>>>
>>> The following variation works:
>>>
>>> protocol P {}
>>>
>>> class P1:P {}
>>>
>>> class X:P1 {}
>>>
>>> func foo(_ x:A) {}
>>>
>>> func bar() {
>>>//let x = X() // this compiles
>>>let x = X() as P1 // this does not compile. Why?
>>>foo(x)
>>> }
>>>
>>> Which adds credence to the bug theory.
>>
>>
>> No it does not.
>> You have made a type out of the parameter. It’s no longer a protocol.
>> IMO the failure here is to understand the difference between a type and a
>> protocol.
>> A type (even if empty) is always a combination of storage with functions
>> (that are assumed to work on the data in storage)
>> A protocol is just a definition of functions without the accompanying data.
>>
>> Rien.
>>
>>
>>
>>>
>>> Note two changes: 1. two levels of inheritance and 2. change to classes. If
>>> you do two levels using protocols it doesn't work if you use either classes
>>> or structs.
>>>
>>>
>>> -- Howard.
>>>
>>> On 23 December 2016 at 07:29, Kevin Nattinger wrote:
>>> I recall seeing a request on the -evolution list for something like `T :=
>>> X` to indicate it could be X itself or anything inheriting / implementing
>>> it, so it’s certainly known behavior, if not desired. IMO it’s a bug and
>>> `:` should be fixed to include the root type, whether or not that requires
>>> a discussion on -evolution.
>>>
>>>> On Dec 22, 2016, at 2:17 PM, Howard Lovatt via swift-users
>>>> wrote:
>>>>
>>>> I suspect a compiler bug since A is a P. The equivalent in Java works:
>>>>
>>>> interface P {}
>>>> class X implements P {}
>>>>
>>>> void foo(A x) {}
>>>>
>>>> void bar() {
>>>>final P x = new X();
>>>>foo(x);
>>>> }
>>>>
>>>> -- Howard.
>>>>
>>>> On 23 Dec 2016, at 3:19 am, Rien via swift-users
>>>> wrote:
>>>>
>>>>> IMO the error message says it all:
>>>>>
>>>>> Playground execution failed: error: MyPlayground8.playground:9:5: error:
>>>>> cannot invoke 'foo' with an argument list of type '(P)'
>>>>> foo(x)
>>>>> ^
>>>>>
>>>>> MyPlayground8.playground:9:5: note: expected an argument list of type
>>>>> '(A)'
>>>>> foo(x)
>>>>> ^
>>>>>
>>>>> I.e. you are passing in a protocol while the function is specified for a
>>>>> type.
>>>>> Said other way: On which data do you expect the protocol to operate?
>>>>>
>>>>> Regards,
>>>>> Rien
>>>>>
>>>>> Site: http://balancingrock.
Re: [swift-users] Weird protocol behaviour.
> On 23 Dec 2016, at 09:43, Mikhail Seriukov wrote:
>
> No it does not.
> You have made a type out of the parameter. It’s no longer a protocol.
> IMO the failure here is to understand the difference between a type and a
> protocol.
> A type (even if empty) is always a combination of storage with functions
> (that are assumed to work on the data in storage)
> A protocol is just a definition of functions without the accompanying data.
>
> I see your point.
> But actually when I write it as `let x = X() as P` I really mean that I want
> `x` to be `AnyObject` but conforming to P, not just protocol itself.
> Is it even possible to downcast it this way?
Yes, but only for a destination that needs a protocol. Not for a destination
that needs a type.
I.e. in the example
protocol P {}
struct X:P {}
func foo(_ x:A) {}
func bar(_ x:P) {}
func bar() {
var p: P
//let x = X() // this compiles
let x = X() as P // this does not compile. Why?
p = x
bar(p)
}
Regards,
Rien.
>
> 2016-12-23 14:51 GMT+07:00 Marinus van der Lugt :
>
>> On 22 Dec 2016, at 22:43, Howard Lovatt wrote:
>>
>> The following variation works:
>>
>> protocol P {}
>>
>> class P1:P {}
>>
>> class X:P1 {}
>>
>> func foo(_ x:A) {}
>>
>> func bar() {
>> //let x = X() // this compiles
>> let x = X() as P1 // this does not compile. Why?
>> foo(x)
>> }
>>
>> Which adds credence to the bug theory.
>
>
> No it does not.
> You have made a type out of the parameter. It’s no longer a protocol.
> IMO the failure here is to understand the difference between a type and a
> protocol.
> A type (even if empty) is always a combination of storage with functions
> (that are assumed to work on the data in storage)
> A protocol is just a definition of functions without the accompanying data.
>
> Rien.
>
>
>
>>
>> Note two changes: 1. two levels of inheritance and 2. change to classes. If
>> you do two levels using protocols it doesn't work if you use either classes
>> or structs.
>>
>>
>> -- Howard.
>>
>> On 23 December 2016 at 07:29, Kevin Nattinger wrote:
>> I recall seeing a request on the -evolution list for something like `T := X`
>> to indicate it could be X itself or anything inheriting / implementing it,
>> so it’s certainly known behavior, if not desired. IMO it’s a bug and `:`
>> should be fixed to include the root type, whether or not that requires a
>> discussion on -evolution.
>>
>>> On Dec 22, 2016, at 2:17 PM, Howard Lovatt via swift-users
>>> wrote:
>>>
>>> I suspect a compiler bug since A is a P. The equivalent in Java works:
>>>
>>> interface P {}
>>> class X implements P {}
>>>
>>> void foo(A x) {}
>>>
>>> void bar() {
>>> final P x = new X();
>>> foo(x);
>>> }
>>>
>>> -- Howard.
>>>
>>> On 23 Dec 2016, at 3:19 am, Rien via swift-users
>>> wrote:
>>>
>>>> IMO the error message says it all:
>>>>
>>>> Playground execution failed: error: MyPlayground8.playground:9:5: error:
>>>> cannot invoke 'foo' with an argument list of type '(P)'
>>>>foo(x)
>>>>^
>>>>
>>>> MyPlayground8.playground:9:5: note: expected an argument list of type '(A)'
>>>>foo(x)
>>>>^
>>>>
>>>> I.e. you are passing in a protocol while the function is specified for a
>>>> type.
>>>> Said other way: On which data do you expect the protocol to operate?
>>>>
>>>> Regards,
>>>> Rien
>>>>
>>>> Site: http://balancingrock.nl
>>>> Blog: http://swiftrien.blogspot.com
>>>> Github: http://github.com/Swiftrien
>>>> Project: http://swiftfire.nl
>>>>
>>>>
>>>>
>>>>
>>>>> On 22 Dec 2016, at 17:05, Mikhail Seriukov via swift-users
>>>>> wrote:
>>>>>
>>>>> Hello community! I' wondering if somebody can explain this to me.
>>>>> Please take look at the snippet.
>>>>>
>>>>> protocol P {}
>>>>> struct X:P {}
>>>>>
>>>>> func foo(_ x:A) {}
>>>>>
>>>>> func bar() {
>>>>>//let x = X() // this compiles
>>>>>let x = X() as P // this does not compile. Why?
>>>>>foo(x)
>>>>> }
>>>>>
>>>>> I expect the both cases to work though. But only first works? And I do
>>>>> not understand why.
>>>>> My coworkers said that it is a compiler bug, but I'm not shure it is.
>>>>> Thanks for the help.
>>>>> ___
>>>>> 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
>>> ___
>>> 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] Weird protocol behaviour.
IMO the error message says it all:
Playground execution failed: error: MyPlayground8.playground:9:5: error: cannot
invoke 'foo' with an argument list of type '(P)'
foo(x)
^
MyPlayground8.playground:9:5: note: expected an argument list of type '(A)'
foo(x)
^
I.e. you are passing in a protocol while the function is specified for a type.
Said other way: On which data do you expect the protocol to operate?
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 22 Dec 2016, at 17:05, Mikhail Seriukov via swift-users
> wrote:
>
> Hello community! I' wondering if somebody can explain this to me.
> Please take look at the snippet.
>
> protocol P {}
> struct X:P {}
>
> func foo(_ x:A) {}
>
> func bar() {
> //let x = X() // this compiles
> let x = X() as P // this does not compile. Why?
> foo(x)
> }
>
> I expect the both cases to work though. But only first works? And I do not
> understand why.
> My coworkers said that it is a compiler bug, but I'm not shure it is.
> Thanks for the help.
> ___
> 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] Implicitly capture a mutating self
Just because it is called “Unsafe” does not mean it is unsafe :-)
It all depends on how you use it.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 16 Dec 2016, at 09:52, Richard Wei wrote:
>
> Zhao, it’s not a class.
>
> Rien, unsafe pointers is the last thing I would ever want to introduce in my
> library…
>
> Capturing self was clean, working perfectly, until Swift 3.0.2.
>
> -Richard
>
>> On Dec 16, 2016, at 02:49, Zhao Xin wrote:
>>
>> What is the type of self? If it is a class, try [unowned self].
>>
>> Zhaoxin
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 16, 2016 at 4:33 PM, Rien via swift-users
>> wrote:
>> How about using:
>>
>> UnsafeMutablePointer
>>
>> ?
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>> > On 16 Dec 2016, at 09:10, Richard Wei via swift-users
>> > wrote:
>> >
>> > Capturing makes it immutable, which unfortunately can't solve this problem.
>> >
>> > -Richard
>> >
>> >> On Dec 16, 2016, at 02:05, Zhao Xin wrote:
>> >>
>> >> I did not test the code. But if you cannot implicitly capture a mutating
>> >> self, you should do it explicitly, right?
>> >>
>> >> let blockSize = min(512, count)
>> >> let blockCount = (count+blockSize-1)/blockSize
>> >> device.sync { [self] () -> () in // Launch CUDA kernel
>> >> try! fill<<<(blockSize, blockCount)>>>[
>> >> .pointer(to: &self), .value(value), .value(Int64(count))
>> >> ]
>> >> }
>> >>
>> >> Hope above code works.
>> >>
>> >> Zhaoxin
>> >>
>> >> On Fri, Dec 16, 2016 at 3:46 PM, Richard Wei via swift-users
>> >> wrote:
>> >> Hi,
>> >>
>> >> Swift 3.0.2 seems to have broken my code due to mutating self capture.
>> >> But I have to pass inout self to the closure. Any workaround?
>> >>
>> >> let blockSize = min(512, count)
>> >> let blockCount = (count+blockSize-1)/blockSize
>> >> device.sync { // Launch CUDA kernel
>> >> try! fill<<<(blockSize, blockCount)>>>[
>> >> .pointer(to: &self), .value(value), .value(Int64(count))
>> >> ]
>> >> }
>> >>
>> >>
>> >>
>> >> -Richard
>> >>
>> >> ___
>> >> 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
>>
>> ___
>> 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] Implicitly capture a mutating self
How about using:
UnsafeMutablePointer
?
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 16 Dec 2016, at 09:10, Richard Wei via swift-users
> wrote:
>
> Capturing makes it immutable, which unfortunately can't solve this problem.
>
> -Richard
>
>> On Dec 16, 2016, at 02:05, Zhao Xin wrote:
>>
>> I did not test the code. But if you cannot implicitly capture a mutating
>> self, you should do it explicitly, right?
>>
>> let blockSize = min(512, count)
>> let blockCount = (count+blockSize-1)/blockSize
>> device.sync { [self] () -> () in // Launch CUDA kernel
>> try! fill<<<(blockSize, blockCount)>>>[
>> .pointer(to: &self), .value(value), .value(Int64(count))
>> ]
>> }
>>
>> Hope above code works.
>>
>> Zhaoxin
>>
>> On Fri, Dec 16, 2016 at 3:46 PM, Richard Wei via swift-users
>> wrote:
>> Hi,
>>
>> Swift 3.0.2 seems to have broken my code due to mutating self capture. But I
>> have to pass inout self to the closure. Any workaround?
>>
>> let blockSize = min(512, count)
>> let blockCount = (count+blockSize-1)/blockSize
>> device.sync { // Launch CUDA kernel
>> try! fill<<<(blockSize, blockCount)>>>[
>> .pointer(to: &self), .value(value), .value(Int64(count))
>> ]
>> }
>>
>>
>>
>> -Richard
>>
>> ___
>> 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
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Overload Resolution of Binary Operators
I seem to remember that while it is possible to define, the compiler will yield
an error if you try to use the functions (“cannot resolve”).
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 14 Nov 2016, at 23:05, Toni Suter via swift-users
> wrote:
>
> Hi,
>
> I would have expected that the following code reports an error, because
> of ambiguous function overloads:
>
> infix operator ***: MultiplicationPrecedence
> infix operator +++: AdditionPrecedence
>
> func ***(x: Int, y: Int) -> String {
> print("f1")
> return ""
> }
>
> func ***(x: Int, y: Int) -> Int {
> print("f2")
> return 0
> }
>
> func +++(x: String, y: Int) -> Int {
> print("f3")
> return 0
> }
>
> func +++(x: Int, y: Int) -> Int {
> print("f4")
> return 0
> }
>
> let result = 0 *** 4 +++ 0// prints f2 and f4
>
>
> As far as I can tell, there are two possible overload resolutions: f1 + f3 or
> f2 + f4.
> I thought that these two solutions get an "equivalent score" and therefore
> there would
> be a compile error. However, that's not the case. Instead, the type checker
> picks
> f2 and f4.
>
> So, I guess my question is, whether there is some rule, that prefers
> operators, which have the same argument types and the same return type
> or whether this is simply a bug.
>
> Thanks and best regards,
> Toni
> ___
> 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] Details of defer statement in Swift
The manual says this: https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html A defer statement is used for executing code just before transferring program control outside of the scope that the defer statement appears in. The scope of a for loop ends when the loop ends. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 10 Nov 2016, at 08:32, Andrea VEH via swift-users > wrote: > > Hello, > From The Swift Programming Language, I learn the defer statements execute > in the reverse order that they appear in the program. And when there are two > or more defer statements in a loop(e.g. a for loop), defer statements execute > still in the reverse order that they appear, but in the loop order that the > loop statement executes. Code snippet is > here(https://swiftlang.ng.bluemix.net/#/repl/582421bfdee52b5745935771). > Early I saw this > thread(https://twitter.com/lexrus/status/796370747849441280) from Twitter, I > am curious about defer statement's execute order. Can you tell more details > about it? > > Best regards, > ___ > 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] The value of enums
As usual: it depends. I use enums with associated values quite a lot. In my experience there is quite a thin line between very convenient and too much. I have several cases where I started off with enums with associated values, only to later convert them to classes. As long as the enums only have an associated value, things tend to work just fine. But as soon as more properties become associated with the enum, things get out of hand. Once I tried to fix a complete inter process protocol in enum’s. And it did work, but maintenance became a nightmare after the protocol implemented more than 10 commands or so. To me the key is: keep them small. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 06 Nov 2016, at 12:07, Tino Heth via swift-users > wrote: > > Enums are a fundamental part of Swift, so I guess they won't change much — > but I wonder if anyone shares my observations in real-life use… > > Afair, there are three different types of enums: > - Enums with raw values > - enums with associated objects > - Plain enums (no underlying value) > > I use the first type quite often (as a convenient way to create string > constants, or for serialization), but see no real value in plain enums (they > offer nothing over enums backed with a raw value). > > The second type is special: > It looks like a really cool concept, and and I started several designs based > on them — just to realize later that structs and classes are a better fit. > My conclusion so far is that enums perform bad as soon as you want to attach > additional data or behavior; one or two computed properties are ok, but those > switch-statements quickly become a burden. > There are some options to work around this problem, but I guess I'll just > stay away from enums with associated objects by default (with the exception > of error-types — imho those can be modeled quite nicely). > > So, that's my current perception, and I'm curious if others had similar > experiences — or, even more interesting, completely different observations > and elegant solutions based on enums. > > - Tino > ___ > 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] Understanding pass-by-value
> On 04 Nov 2016, at 17:48, Ryan Lovelett wrote: > >> I often end up “printing” the addresses or using GDB to take an inside >> look. > > That is a really simple interrogation technique I wish I had thought of > that! Thank you! > >> One thing that tripped me up: if you use inout variables, the observers >> will be triggered once the function completes. Even if the function never >> changed the data referred to. (This is now documented behaviour) > > Could you provide a link to such documentation? I think that would be > interesting to read. https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Properties.html#//apple_ref/doc/uid/TP40014097-CH14-ID254 Check the last ‘note’ in the Property Observer section. You can also follow the link in there for more. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Understanding pass-by-value
> On 04 Nov 2016, at 13:59, Ryan Lovelett via swift-users
> wrote:
>
> struct Foo {
> init(from buffer: Data) {
> bar = integer(withBytes: Array(buffer[4..<6]))
> baz = integer(withBytes: Array(buffer[6..<8]))
> ...
> }
>
> let d = Data(count: Int(3e+8))
> let f = Foo(from: d)
>
> Did I just make two copies of the `Data`? How would I investigate this
> to understand it?
I often end up “printing” the addresses or using GDB to take an inside look.
However those snippets of inside information obtained that way are not
necessary useful outside the specific problem that was studied.
As Brent already hinted: the compiler will generate different code in different
situations. And for an outsider it is not always easy to understand why which
code was generated.
The best approach imo is to “trust” the compiler and only start such
investigations if you experience performance problems.
One thing that tripped me up: if you use inout variables, the observers will be
triggered once the function completes. Even if the function never changed the
data referred to. (This is now documented behaviour)
>
> I _think_ that if I made it `inout` then it would not make a copy but
> now the data buffer is mutable. I want it to be clear I'm not mutating
> the buffer inside the initializer but I also want to be sure I'm not
> making a copy of the buffer either.
>
> Help?
>
> --
> Ryan Lovelett
> r...@lovelett.me
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] What is "binding" memory?
> On 03 Nov 2016, at 23:58, Manfred Schubert via swift-users > wrote: > > Am 03.11.2016 um 15:41 schrieb Rien : >> >> Ah, but that is not the case. >> >> It is important to differentiate between the “gateway” to the memory and the >> memory area itself. >> Different programming languages/compilers have different approaches, but I >> believe that Swift allocates a struct for every gateway. >> widePtr and narrowPtr are two different gateways. They refer to different >> struct's. But the struct for each of them refers to the same memory area. > > When you have a look at the Swift memory model explanation > > https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation > > it looks like memory can only be bound to one type at a time. In particular > in the third example where a pointer of type T is used to initialize memory > which is bound to type U, it says that the behavior is undefined. > > There is also withMemoryRebound(to:capacity:) which binds memory to another > type, executes the code that accesses the memory as this type in a closure, > and the restores the old type binding. > > That makes me think that it is not allowed to have multiple „gateways“ to the > same memory area at the same time. > It only means that memory access must be typed, not existence. > > Manfred > ___ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] What is "binding" memory?
Thanks Any, most informative.
So the pointer “gateway’s” are in fact ephemeral. That is good for performance.
As to the low level interfaces, are you aware of any effort that addresses the
POSIX socket functions?
(Things like ‘addrinfo')
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 04 Nov 2016, at 06:24, Andrew Trick wrote:
>
>>
>> On Nov 3, 2016, at 7:41 AM, Rien via swift-users
>> wrote:
>>
>>> On 03 Nov 2016, at 15:16, Manfred Schubert via swift-users
>>> wrote:
>>>
>>>
>>>> Am 02.11.2016 um 18:37 schrieb Rien :
>>>>
>>>>>>
>>>>>> var rawPtr = UnsafeMutableRawPointer.allocate(bytes: 2, alignedTo: 0)
>>>>>>
>>>>>> var widePtr = rawPtr.bindMemory(to: Int16.self, capacity: 1)
>>>>>>
>>>>>> widePtr.pointee = 32
>>>>>>
>>>>>> var narrowPtr = rawPtr.bindMemory(to: UInt8.self, capacity: 2)
>>>>>>
>>>>>> narrowPtr[0] = 16
>>>>>> narrowPtr[1] = 255
>>>>>>
>>>>>> print(widePtr.pointee)
>>>>>
>>>>> This compiles and runs as expected, but it should not be allowed if I
>>>>> understand things correctly. So shouldn’t it be a compile time error or
>>>>> crash at runtime? If not, what do I get over how it was before where I
>>>>> was casting to a typed pointer?
>>>>
>>>> Why do you think it should not be allowed.
>>>> AFAICS everything is correct.
>>>
>>> If I understand the documentation correctly, this should not be allowed,
>>> because it’s not allowed to access memory as different types at the same
>>> time. It needs to be „bound“ to the type first, and can only be bound to
>>> one type at a time, so all access as another type must be encapsulated
>>> within a closure.
>>>
>>
>> Ah, but that is not the case.
>>
>> It is important to differentiate between the “gateway” to the memory and the
>> memory area itself.
>> Different programming languages/compilers have different approaches, but I
>> believe that Swift allocates a struct for every gateway.
>> widePtr and narrowPtr are two different gateways. They refer to different
>> struct's. But the struct for each of them refers to the same memory area.
>
> In the Swift memory model, a pointer value is substitutable with any other
> pointer of the same value. And for efficiency, pointer values are implemented
> as addresses. This was an intentional design decision. For example, this is
> well-defined:
>
> func foo(rawPtr: UnsafeRawPointer, ptrT: UnsafePointer) {
> if rawPtr == UnsafeRawPointer(ptrT) {
> assert(rawPtr.assumingMemoryBound(to: T.self).pointee == ptrT.pointee)
> }
> }
>
> Note that assumingMemoryBound(to:) is essentially a nice way of doing
> unsafeBitCast, but intentional and verifiable.
>
>> Example: widePtr can be located at address 0x1000, narrowPtr can be
>> allocated at address 0x2000 while the memory area both refer to (the raw
>> memory) can be at address 0x3000
>
> Swift strict aliasing means that unrelated typed accesses to memory cannot
> overlap in their underlying raw memory.
>
> Our UnsafePointer value representation is not realistically ever going to
> depend on the Pointee type.
>
>> Every access to the raw memory via a gateway must follow the rules for that
>> gateway.
>
>> Note: Some compilers may only create ephemeral gateways, but as long as the
>> compiler checks that the acces follows the correct rules, that is not a
>> problem.
>>
>> This is not only very useful, but it also opens the door to better
>> interfaces to some low level Unix APIs.
>
> I think we would want a Swift interface on top of those APIs that doesn’t
> rely on type punning.
>
> A Swift pointer value itself doesn’t provide a gateway. It is really
> bindMemory(to:capacity:) or withMemoryRebound(to:capacity:) that control
> whether typed access is well-defined at some point in the program.
>
> In native Swift code, interacting with the memory binding APIs will be
> extremely rare. Type punning is not a “normal” activity outside of use cases
> like network I/O and binary file formats. In those cases it probably makes
> more sense to use a raw pointer directly rather than binding memory to a type.
>
> -Andy
>
>>
>>
>>>
>>> Manfred
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>> Regards,
>> Rien
>>
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>>
>>
>>
>>
>> ___
>> 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
