Re: [swift-users] Custom operators in a framework

[Rien via swift-users]

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

[swift-users] unsafeBitCast to Unimplemented Class

[Saagar Jha via swift-users]

Hello,

I’m having an issue migrating some old Objective-C code that looks like this:

@implementation Foo

- (void)load {
// Swizzle one of Bar’s methods to call Foo’s baz method
}

- (void)baz {
[self baz];
if ([self isKindOfClass:NSClassFromString(@“Bar”)]) {
Bar *bar = (Bar *)self; // I can’t migrate this
// work with bar
}
}

@end

I’m trying to cast self to a Bar at runtime, and use it to call Bar’s methods. 
Sounds like an easy to task for unsafeBitCast, right? The issue is that I don’t 
have access to the implementation of Bar’s class at compile time (this is a 
plugin, so it’s loaded by another application which contains Bar). In 
Objective-C I can create a header and stick a dummy interface for Bar in it; 
the cast will work if Bar exists at runtime. However, in Swift, unsafeBitCast 
requires me to use Bar.self, which does not exist. Is there any way to get this 
cast to work?

Thanks,
Saagar Jha

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

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

[Howard Lovatt via swift-users]

Why not add to the library:

extension Sequence {
func forEach(_ eacher: (Iterator.Element) throws -> Void, elser: ()
throws -> Void) rethrows {
var hasIterated = false
for element in self {
hasIterated = true
try eacher(element)
}
guard hasIterated else {
try elser()
return
}
}
}

On Fri, 3 Feb 2017 at 8:33 pm, Jeremy Pereira via swift-users <
swift-users@swift.org> wrote:

>
> > On 2 Feb 2017, at 20:12, Erica Sadun via swift-users <
> swift-users@swift.org> wrote:
> >
> > I've taken this over to Swift Users from Swift Evolution.
> >
> > I think you'd want to handle the exceptional case first,
>
> Although it is the way I would do it for an array, sometimes you don’t
> know that a sequence is empty until after you have iterated it.
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
-- 
-- Howard.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Custom operators in a framework

[Jordan Rose via swift-users]

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] Swift 101: JSON or XML?

[Jens Alfke via swift-users]

> On Feb 3, 2017, at 5:00 AM, Roy Henderson via swift-users 
>  wrote:
> 
> 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.

Probably JSON. It’s usually a lot easier for clients to parse than XML. If 
you’re thinking about web clients, JSON is the most natural data format for 
JavaScript to work with. Another issue is that even generating XML can be a 
minefield unless you have a solid library to do it for you — I used to work on 
an RSS/Atom reader, and encountered so many news feeds that generated broken 
XML due to ignoring subtleties of quoting and name spacing. And parsing broken 
XML is even more difficult than parsing correct XML, because a regular XML 
parser is required to reject it entirely.

(But XML does have the advantage of a richer data model, with names to identify 
different elements, which makes it more self-describing; in JSON you often have 
to have either an informal schema describing what different objects represent, 
or explicitly add a property like “type”: to identify an object. This actually 
helps a lot if you’re parsing to native objects, since you can easily set up a 
mapping from XML element names to native classes.)

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

Re: [swift-users] Custom operators in a framework

[Rien via swift-users]

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

[Jordan Rose via swift-users]

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] Debugger woes

[Jim Ingham via swift-users]

> On Feb 3, 2017, at 6:55 AM, Maury Markowitz  wrote:
> 
>> On Jan 31, 2017, at 1:59 PM, Jim Ingham  wrote:
>> 
>> From the symptoms, it looks like the compiler is not holding onto 
>> "background" because it is no longer used.  That's a desirable thing to do 
>> for optimized code, but not at -O0.
>> 
>> What happens if you rewrite this to:
>> 
>>  let background = sceneView.snapshot().cgImage!
>>  let cropped = background.cropping(to: overlayView.frame)
>>  UIGraphicsBeginImageContextWithOptions(overlayView.frame.size, 
>> false, 1.0)
>>   print(background)
> 
> I've been battling H3N2 so I only got a chance to try this now. Indeed, the 
> 'background' variable is "alive" in this version, I assume because of the 
> print() that follows?

Yes, that's most likely right.

> 
> Should I file through the normal Apple Bug Reporter, or is there a better 
> mechanism for Swift-related issues?

The official word on that is:

https://swift.org/contributing/#reporting-bugs

Jim

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

Re: [swift-users] Swift 101: JSON or XML?

[Maury Markowitz via swift-users]

Technically there is little to chose one over the other. I find working with 
JSON on Swift is somewhat easier than XML however, and that should not be a 
minor consideration.

However, moving forward it seems that JSON will be more widely used and basing 
your comms on that is likely a very good idea. For instance, there are any 
number of modern databases who's native format is JSON, and you're more likely 
to end up on one of them than the (generally older) servers that use XML. 
Additionally, I find it reasonable to suggest that in the future there will be 
much more JSON code and knowledge to draw on from the community.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 101: JSON or XML?

[Rien via swift-users]

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

Re: [swift-users] Swift 101: JSON or XML?

[Saagar Jha via swift-users]

Either should be fine, but in my experience JSON is a lot easier to work with 
due as compared to XML since JSONSerialization being simpler than XMLParser.

Saagar Jha

> On Feb 3, 2017, at 5:00 AM, 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

Re: [swift-users] Debugger woes

[Maury Markowitz via swift-users]

> On Jan 31, 2017, at 1:59 PM, Jim Ingham  wrote:
> 
> From the symptoms, it looks like the compiler is not holding onto 
> "background" because it is no longer used.  That's a desirable thing to do 
> for optimized code, but not at -O0.
> 
> What happens if you rewrite this to:
> 
>   let background = sceneView.snapshot().cgImage!
>   let cropped = background.cropping(to: overlayView.frame)
>   UIGraphicsBeginImageContextWithOptions(overlayView.frame.size, 
> false, 1.0)
>print(background)

I've been battling H3N2 so I only got a chance to try this now. Indeed, the 
'background' variable is "alive" in this version, I assume because of the 
print() that follows?

Should I file through the normal Apple Bug Reporter, or is there a better 
mechanism for Swift-related issues?


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

[swift-users] Swift 101: JSON or XML?

[Roy Henderson via swift-users]

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

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

[Jeremy Pereira via swift-users]

> On 2 Feb 2017, at 20:12, Erica Sadun via swift-users  
> wrote:
> 
> I've taken this over to Swift Users from Swift Evolution.
> 
> I think you'd want to handle the exceptional case first,

Although it is the way I would do it for an array, sometimes you don’t know 
that a sequence is empty until after you have iterated it.


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