[swift-users] Hexadecimal floating-point literals

2016-06-26 Thread Toni Suter via swift-users
Hi, I have a question regarding hexadecimal floating-point literals. According to the Lexical Structure (https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html

Re: [swift-users] Hexadecimal floating-point literals

2016-06-26 Thread Toni Suter via swift-users
Ok, thanks for the hint! Toni > On 26 Jun 2016, at 11:49, zh ao wrote: > > I think it avoids the confusion. You can use print((0xabc).beef) instead. > > Zhaoxin > > On Sun, Jun 26, 2016 at 3:50 PM, Toni Suter via swift-users > mailto:swift-users@swift.org>&

[swift-users] SPM: Subfolders in a Module

2016-09-15 Thread Toni Suter via swift-users
Hi everyone, Let's assume there's a Swift package with the following Layout: MyPackage/ ├── Package.swift └── Sources └── MyModule ├── SubFolder │ └── MyClass.swift └── main.swift As far as I can tell, there's still just one module called MyModule and the subfolder

Re: [swift-users] SPM: Subfolders in a Module

2016-09-16 Thread Toni Suter via swift-users
Ok, thank you very much! Best regards Toni > Am 16.09.2016 um 07:26 schrieb Ankit Agarwal : > > > > On Fri, Sep 16, 2016 at 12:21 AM, Toni Suter via swift-users > mailto:swift-users@swift.org>> wrote: > Hi everyone, > > Let's assume there'

[swift-users] Function overload resolution rules

2016-09-30 Thread Toni Suter via swift-users
Hi, I am trying to get a better understanding of Swift's function overload resolution rules. As far as I can tell, if there are multiple candidates for a function call, Swift favors functions for which the least amount of parameters have been ignored / defaulted. For example: // Example 1 func

Re: [swift-users] Function overload resolution rules

2016-09-30 Thread Toni Suter via swift-users
I created a bug report here: https://bugs.swift.org/browse/SR-2810 <https://bugs.swift.org/browse/SR-2810> Best regards, Toni > Am 30.09.2016 um 19:47 schrieb Mark Lacey : > >> >> On Sep 30, 2016, at 5:02 AM, Toni Suter via swift-users >> mailto:swift-user

[swift-users] Overload Resolution

2016-10-06 Thread Toni Suter via swift-users
Hi, Does someone know a good explanation / summary of Swift's overload resolution rules? After reading https://github.com/apple/swift/blob/master/docs/TypeChecker.rst I understand that the overloading resolution happens as part of

Re: [swift-users] Overload Resolution

2016-10-06 Thread Toni Suter via swift-users
Hi Mark, Thanks for pointing me into the right direction! Best regards, Toni > Am 06.10.2016 um 16:31 schrieb Mark Lacey : > > >> On Oct 6, 2016, at 4:53 AM, Toni Suter via swift-users >> mailto:swift-users@swift.org>> wrote: >> >> Hi, >> >

[swift-users] Element vs. Iterator.Element

2016-10-31 Thread Toni Suter via swift-users
Hi, This extension on Array works as expected: extension Array where Element: CustomStringConvertible { func f(_ x: Element) -> String { return x.description } } But when I use Iterator.Element instead, I get an error message (error: value of type 'Element' has no member 'descri

Re: [swift-users] Element vs. Iterator.Element

2016-11-01 Thread Toni Suter via swift-users
Ok, I have filed a bug: https://bugs.swift.org/browse/SR-3102 Best regards, Toni > Am 31.10.2016 um 19:32 schrieb Dave Abrahams via swift-users > : > > > on Mon Oct 31 2016, Toni Suter > wrote: > >> Hi, >> >> This ex

[swift-users] Overload Resolution of Binary Operators

2016-11-14 Thread Toni Suter via swift-users
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)

Re: [swift-users] Overload Resolution of Binary Operators

2016-11-15 Thread Toni Suter via swift-users
://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 amb

[swift-users] Existentials in Swift

2016-11-21 Thread Toni Suter via swift-users
Hi everyone, I am trying to understand existentials in Swift. I understand that in the following code, P1 & P2 is an existential type, because it supports values from all types that conform to both P1 and P2. protocol P1 {} protocol P2 {} var x: P1 & P2 However, this raises a few questions for

Re: [swift-users] Existentials in Swift

2016-11-21 Thread Toni Suter via swift-users
Hi Karl, > 1. Yes > 2. Yes > 3. I don't know the actual reason, but Any and AnyObject have special meaning > to the compiler and objects implicitly "conform"" to them. Either the > implementation doesn't support extending those types, or we explicitly > decided that extending these implicit exi

[swift-users] Type inference of array element type

2017-03-24 Thread Toni Suter via swift-users
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 an

Re: [swift-users] Type inference of array element type

2017-03-24 Thread Toni Suter via swift-users
ference 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: ht

Re: [swift-users] Type inference of array element type

2017-03-24 Thread Toni Suter via swift-users
uire 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

Re: [swift-users] Type inference of array element type

2017-03-24 Thread Toni Suter via swift-users
Ok, I submitted a bug report (https://bugs.swift.org/browse/SR-4347 <https://bugs.swift.org/browse/SR-4347>) and I'll try to fix it in the next few days. Thanks and best regards Toni > Am 24.03.2017 um 18:51 schrieb Mark Lacey : > >> >> On Mar 24, 2017, at 3:08 A

[swift-users] "swift package describe" performs fetch

2017-04-06 Thread Toni Suter via swift-users
Hi everyone, I would like to obtain detailed information about a package and all its dependencies in an automated fashion. At first I thought that the two commands "swift package describe" and "swift package show-dependencies" are a perfect fit for that. More concretely, I wanted to perform the

Re: [swift-users] "swift package describe" performs fetch

2017-04-10 Thread Toni Suter via swift-users
; <http://bugs.swift.org/>? > > On Thu, Apr 6, 2017 at 9:10 PM, Toni Suter via swift-users > mailto:swift-users@swift.org>> wrote: > Hi everyone, > > I would like to obtain detailed information about a package and all its > dependencies in an automated fashion.

[swift-users] Wrapping ImageMagick in a Swift Package

2017-10-03 Thread Toni Suter via swift-users
Hi, I am trying to create a Swift Package that wraps the ImageMagick C API. So I installed ImageMagick using MacPorts and I was then able to build the sample program with the following commands: export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig cc main.c `pkg-config --cflags --libs MagickWand` Th

Re: [swift-users] Wrapping ImageMagick in a Swift Package

2017-10-03 Thread Toni Suter via swift-users
endency and then try to > import the `TestPkg` module that you defined in the modulemap. The error here > is bogus and is tracked by https://bugs.swift.org/browse/SR-5383 > <https://bugs.swift.org/browse/SR-5383> > > On Tue, Oct 3, 2017 at 12:32 AM, Toni Suter via swift-users

Re: [swift-users] A confusing protocol extension behaviour/bug

2018-01-01 Thread Toni Suter via swift-users
Hi Marc, There are several subtleties here, but I think the compiler is actually doing the right thing. The second class defines a static property that looks like it is 'overriding' the static property from the protocol extension, but since the types don't match (String vs. String?), it sort o

Re: [swift-users] A confusing protocol extension behaviour/bug

2018-01-02 Thread Toni Suter via swift-users
Hi Marc, >> The second class defines a static property that looks like it is >> 'overriding' the static property from >> the protocol extension, but since the types don't match (String vs. >> String?), it sort of 'overloads' >> the property (similar to function overloading). Nevertheless, the cl

Re: [swift-users] A confusing protocol extension behaviour/bug

2018-01-02 Thread Toni Suter via swift-users
Yes, I think I agree with you. Maybe we are missing something, but I don't see a reason why declaring a property with the same name and a different type should be allowed in the 1. scenario. So maybe you should file a bug in JIRA, after all. Best regards, Toni > Am 02.01.2018 um 13:56 schrieb Ma