Re: [swift-users] FloatingPoint/BinaryFloatingPoint protocol and concrete FloatingPoint types

[David Sweeris via swift-users]

Sorry, mostly I was just commenting on what I now see was an incorrect 
interpretation of the “// but something actually requiring high precision ...” 
comment in your example code. I’d read it as... you know, I’m not sure what I’d 
though it said... I think something that implied the code would convert the 
`Float80` data to another format with higher precision.

My mistake for not reading more carefully before replying.

- Dave Sweeris 

> On Dec 3, 2017, at 15:22, Jens Persson  wrote:
> 
> I'm not sure what you mean David. That function was just part of my attempt 
> at presenting a solution to Antonino's question (that particular function is 
> from Antonino's code).
> Below is my solution to Antonino's problem again, including a perhaps clearer 
> comment in that function:
> 
> protocol Float80Convertible : BinaryFloatingPoint {
> init(_ value: Float80)
> var float80: Float80 { get }
> }
> extension Double : Float80Convertible {
> var float80: Float80 { return Float80(self) }
> }
> extension Float : Float80Convertible {
> var float80: Float80 { return Float80(self) }
> }
> 
> func maxPrecisionCalculation(input:Float80) -> Float80 {
> return inpu
> // In the actual use case, this would of course not just
> // return input. Instead it would perform some computation
> // that (in contrast to just returning input) actually needs
> // the high precision of Float80.
> }
> 
> func someComplexCalculation(input: T) -> T {
> let input80 = input.float80
> let output80 = maxPrecisionCalculation(input: input80)
> return T(output80)
> }
> 
> /Jens
> 
> 
>> On Fri, Dec 1, 2017 at 11:59 PM, David Sweeris  wrote:
>> 
>> 
>>> On Dec 1, 2017, at 13:18, Jens Persson via swift-users 
>>>  wrote:
>>> 
>>> func maxPrecisionCalculation(input:Float80) -> Float80 {
>>> return input // but something actually reauiring high precision ...
>>> }
>> 
>> AFAIK, Float80 is the high precision format on macOS (well, Intel macs, 
>> anyway... can’t recall if Swift can target OSs old enough to run on PPC 
>> macs). I’d avoid using it, though. AFAIK it’s an x86-only format (it might 
>> even be Intel-only... 5-10 minutes of googling didn’t give me a clear answer 
>> on whether AMD’s CPUs support it).
>> 
>> I don’t know what we do with it on ARM targets, and I’m not at my computer 
>> to try to figure out.
>> 
>> Unless maybe the x86 or ARM vector extensions support 128 or 256 bit floats? 
>> I don’t think they do, but I’m not 100% on that.
>> 
>> - Dave Sweeris
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] FloatingPoint/BinaryFloatingPoint protocol and concrete FloatingPoint types

[David Sweeris via swift-users]

> On Dec 1, 2017, at 13:18, Jens Persson via swift-users 
>  wrote:
> 
> func maxPrecisionCalculation(input:Float80) -> Float80 {
> return input // but something actually reauiring high precision ...
> }

AFAIK, Float80 is the high precision format on macOS (well, Intel macs, 
anyway... can’t recall if Swift can target OSs old enough to run on PPC macs). 
I’d avoid using it, though. AFAIK it’s an x86-only format (it might even be 
Intel-only... 5-10 minutes of googling didn’t give me a clear answer on whether 
AMD’s CPUs support it).

I don’t know what we do with it on ARM targets, and I’m not at my computer to 
try to figure out.

Unless maybe the x86 or ARM vector extensions support 128 or 256 bit floats? I 
don’t think they do, but I’m not 100% on that.

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

Re: [swift-users] Justification for Swift Design Decisions?

[David Sweeris via swift-users]

Specifically WRT to double quotes for characters, the Commonly Rejected Changes 
doc (https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md) 
says, "Swift takes the approach of highly valuing Unicode. However, there are 
multiple concepts of a character that could make sense in Unicode, and none is 
so much more commonly used than the others that it makes sense to privilege 
them. We'd rather save single quoted literals for a greater purpose (e.g. 
non-escaped string literals)."

Otherwise, off the top of my head I'm not sure. If it's a particularly 
controversial decision, there's a fair chance it's come up on the 
swift-evolution list, though, so maybe search its archives?

Hope that helps,
- Dave Sweeris

> On Oct 31, 2017, at 8:52 AM, Michael Rogers via swift-users 
>  wrote:
> 
> Hi, All:
> 
> I’m giving a presentation on Swift this weekend, and am trying to find 
> justification for some of the design decisions that they made. Is there 
> anything out there that goes into the detail of this? Like … why did the use 
> “ for characters, or \() for String interpolation?
> 
> Thanks,
> 
> 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] Re-initializing lazy vars

[David Sweeris via swift-users]

I don't know. IIRC (big if), though, there was talk of adding support for 
"property behaviors"(?). Resetting lazy vars probably would've been one of 
them, and if so, it probably got pulled so that we wouldn't risk breaking 
source compatibility later by adding a consistent syntax for other behaviors. I 
think. I wish I could remember who'd brought up the idea... they'd probably 
know straight away if that's what happened.

- Dave Sweeris

> On Oct 19, 2017, at 5:40 PM, Rick Mann via swift-users 
>  wrote:
> 
> Googling for the answer, it seemed some versions of Swift supported setting a 
> lazy var property to nil, such that the next time it's accessed, the 
> initializer would be run again.
> 
> But I just tried this in a playground in Swift 4 and it doesn't work.
> 
> It sure seems to me like it should work. What's the reasoning for the current 
> behavior?
> 
> -- 
> 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] dealing with heterogenous lists/dictionary with Codable

[David Sweeris via swift-users]

Oh! Yeah, my bad... You are correct; I'd started thinking like I was on 
-evolution instead of -users.


> On Oct 19, 2017, at 1:29 PM, Itai Ferber  wrote:
> 
> Mm, the point I’m trying to get at here is that JSON is inherently untyped 
> while Swift is strongly typed, and the two don’t line up.
> It doesn’t really make sense to ask to decode an existential because there’s 
> not enough type information to influence what you get back.
> 
> On 19 Oct 2017, at 13:20, David Sweeris wrote:
> 
> I think if you can figure that out, you’re halfway to letting protocols 
> conform to themselves.
> 
> (Syntactically, I would probably say that something like “Codable.Self” would 
> read well, but I think that already means something. Maybe the answer will 
> become clearer when we rework the reflection APIs?)
> 
> Sent from my iPhone
> 
> On Oct 19, 2017, at 13:13, Itai Ferber  > wrote:
> 
>> Even then, that wouldn’t necessarily help in the general case. If you decode 
>> {"key" : 1} as [String : Codable], what concrete type would 1 have? Int? 
>> Double? Int8? (Arguments can be made for any one of these, but the key here 
>> is that it is inherently ambiguous and there isn’t necessarily a good 
>> answer.)
>> 
>> On 19 Oct 2017, at 12:57, David Sweeris wrote:
>> 
>> On Oct 19, 2017, at 12:50 PM, David Baraff via swift-users 
>> > wrote:
>> 
>> Yes; this is a case where anywhere in the code base I want to just say
>> struct MyNewType : Codable {
>> // add codable datatypes
>> }
>> 
>> and don’t want/can’t always go to the centralized place to add it in.
>> Is there some extension-like trick I can pull off that lets me spread the 
>> implementation out over different files/libraries?
>> 
>> Ah, ok.
>> 
>> No, I don't think you'll be able to do that until/unless Swift gets more 
>> macro/metaprogramming features. Maybe if protocols ever get to conform to 
>> themselves? That's a common request, but implementing it is apparently 
>> beyond tricky. I'm pretty sure somebody's working on it, but "bigger fish" 
>> and all that...
>> 
>> - Dave Sweeris
>> 
> 

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

Re: [swift-users] dealing with heterogenous lists/dictionary with Codable

[David Sweeris via swift-users]

I think if you can figure that out, you’re halfway to letting protocols conform 
to themselves.

(Syntactically, I would probably say that something like “Codable.Self” would 
read well, but I think that already means something. Maybe the answer will 
become clearer when we rework the reflection APIs?)

Sent from my iPhone

> On Oct 19, 2017, at 13:13, Itai Ferber  wrote:
> 
> Even then, that wouldn’t necessarily help in the general case. If you decode 
> {"key" : 1} as [String : Codable], what concrete type would 1 have? Int? 
> Double? Int8? (Arguments can be made for any one of these, but the key here 
> is that it is inherently ambiguous and there isn’t necessarily a good answer.)
> 
> On 19 Oct 2017, at 12:57, David Sweeris wrote:
> 
> On Oct 19, 2017, at 12:50 PM, David Baraff via swift-users 
>  wrote:
> 
> Yes; this is a case where anywhere in the code base I want to just say
> struct MyNewType : Codable {
> // add codable datatypes
> }
> 
> and don’t want/can’t always go to the centralized place to add it in.
> Is there some extension-like trick I can pull off that lets me spread the 
> implementation out over different files/libraries?
> 
> Ah, ok.
> 
> No, I don't think you'll be able to do that until/unless Swift gets more 
> macro/metaprogramming features. Maybe if protocols ever get to conform to 
> themselves? That's a common request, but implementing it is apparently beyond 
> tricky. I'm pretty sure somebody's working on it, but "bigger fish" and all 
> that...
> 
> - Dave Sweeris
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] dealing with heterogenous lists/dictionary with Codable

[David Sweeris via swift-users]

> On Oct 19, 2017, at 12:50 PM, David Baraff via swift-users 
>  wrote:
> 
> Yes; this is a case where anywhere in the code base I want to just say
>   struct MyNewType : Codable {
>   // add codable datatypes
>   }
> 
> and don’t want/can’t always go to the centralized place to add it in.
> Is there some extension-like trick I can pull off that lets me spread the 
> implementation out over different files/libraries?

Ah, ok.

No, I don't think you'll be able to do that until/unless Swift gets more 
macro/metaprogramming features. Maybe if protocols ever get to conform to 
themselves? That's a common request, but implementing it is apparently beyond 
tricky. I'm pretty sure somebody's working on it, but "bigger fish" and all 
that...

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

Re: [swift-users] Detect if a generic type is numeric

[David Sweeris via swift-users]

> On Oct 4, 2017, at 18:30, Kevin Lundberg via swift-users 
>  wrote:
> 
> Can you do something like this?
> 
> func isNumber(_ value: T) -> Bool { return true }
> 
> func isNumber(_ value: T) -> Bool { return false }
> 
> I don't recall whether or not swift will pick the right version of the 
> function here, or whether this can even compile (mac isnt open at the 
> moment), but if you can overload functions in this way then it might be much 
> nicer than checking for lots of concrete types.
> 

It’ll compile, but you’ll get the wrong answer if it’s called from another 
generic function that isn’t similarly overloaded for `T` vs `T: Numeric`. I’m 
not at my computer right now, but IIRC, this is correct:

func foo (_ value:T) -> Bool {
return isNumber(value)
}
func bar (_ value:T) -> Bool {
return isNumber(value)
}
func bar (_ value:T) -> Bool {
return isNumber(value)
}
isNumber(0) //true
isNumber(“”) //false
foo(0) //false
foo(“”) //false
bar(0) //true
bar(“”) //false

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

Re: [swift-users] bigintegers

[David Sweeris via swift-users]

I don't know that there are any plans to implement big integers in the standard 
library. There's at least one open-source implementations, though: 
https://github.com/attaswift/BigInt

Good luck with your class! :-)

- Dave Sweeris

> On Sep 19, 2017, at 8:12 PM, Muhammad Tahir Vali via swift-users 
>  wrote:
> 
> hello,
> 
> im in a crypto class. we had to compute with big integers and i found out 
> swift 4 doesnt support BigIntegers but the new integer protocol can pave the 
> way to help create it. 
> 
> I want to know how immediate the plans to implement it in the standard 
> library and if there was any help needed to create one. Some key points to 
> keep in mind would be helpful with swift context. Thank you!
> 
> I checked this out too! Pretty awesome
> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>  
> 
> 
> 
>  
> -- 
> Best Regards,
> 
> Muhammad T. Vali
> ___
> 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-build-dev] SwiftPM manual dependency management

[David Sweeris via swift-users]

> On Jul 22, 2017, at 16:09, David Sweeris via swift-build-dev 
>  wrote:
> 
> Within the past day or so, someone on evolution rezzed Ted's announcement 
> thread on the matter.

Whoops, I was wrong, it's a new thread called "Setting expectations on when we 
move to Discourse"___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-build-dev] SwiftPM manual dependency management

[David Sweeris via swift-users]

> On Jul 22, 2017, at 12:07, Geordie J  wrote:
> 
> 
>> Am 22.07.2017 um 19:46 schrieb David Sweeris :
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Jul 22, 2017, at 05:16, Geordie Jay via swift-build-dev 
>>>  wrote:
>>> 
>>> How can I get involved in the evolution of this? The evolutions are always 
>>> uneditable uncommentable markdown files on a repo somewhere and the mailing 
>>> lists are in my practical experience inpentrible especially for entries you 
>>> weren't subscribed to the list for, or were "only" subscribed to the digest 
>>> for. I wish they were on google docs or a hackpad equivalent. Is there 
>>> "officially recognised" discussion on the SwiftPM dev slack channel 
>>> regarding evolution topics?
>> 
>> Yeah, I'm not a mailing list fan, either (at least for long or active 
>> threads), and you have nicely summarized the reasons we decided to move to a 
>> discourse server. It's just that it hasn't happened yet.
>> 
>> To answer your question more directly, you can of course discuss things on 
>> slack, twitter, in-person, off-list email, or in any other way, but AFAIK of 
>> you want your conversation to be "on-record", you need to have it on-list. 
>> Until we move to discourse, of course.
>> 
>> I realize that doesn't actually solve the problem, I hope it at least gives 
>> you some moral support.
>> 
>> - Dave Sweeris (who speaks only for himself and shouldn't be taken as 
>> official source of information on this matter)
> 
> This is morale-boosting news! Was this discussed somewhere public? I can 
> hardly wait, and would be willing to put some of my spare time into 
> facilitating the move if that’s at all interesting to those making the 
> decisions on this one.

Yay! morale += 1 

Yeah, I can't remember if it was a formal proposal, but it was discussed 
extensively on the swift-evolution list a while back (maybe late last year or 
early this year, I think?), and the conclusion was that we'd move to Discourse 
(it has a mailing list mode, for the people who prefer that). In any case, I'd 
imagine it hasn't happened yet simply because the people who'd need to be 
involved are slammed with trying to meet the 4.0 release deadline.

Within the past day or so, someone on evolution rezzed Ted's announcement 
thread on the matter. I'd guess that'd be as good a place as any to start, if 
you want to try to get "the ones making the decisions" to let you help.

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

Re: [swift-users] Can I use a tuple to force a certain memory layout?

[David Sweeris via swift-users]

> On Jul 21, 2017, at 07:55, Johannes Weiß via swift-users 
>  wrote:
> 
>> On 21 Jul 2017, at 1:45 am, Taylor Swift  wrote:
>> 
>> Okay, apparently layout is only guaranteed if the reference is to the tuple 
>> itself, not a member of the tuple. Don’t know if this is a bug or intended 
>> behavior. The above code works when written as 
>> 
>>var buffers:(VBO:GL.UInt, EBO:GL.UInt) = (0, 0)
>>withUnsafeMutablePointer(to: )
>>{
>>$0.withMemoryRebound(to: UInt32.self, capacity: 2)
>>{
>>glGenBuffers(n: 2, buffers: $0)
>>}
>>}
> 
> this is legal now as you're now observing the whole tuple rather than just 
> one value. That means they're now guaranteed to be in standard C layout.
> 
> In other words, Swift could have the tuple in memory like this
> 
> +-+--+-+
> | VBO | whatever | EBO |
> +-+--+-+
>   ^ ^ ^
>   | | |
>   a b c
> 
> when you now get a pointer to , you'll get the pointer 'a' and as 
> you see, you'll not be guaranteed to have EBO right next to it.
> 
> It you however request a pointer to `buffers` as a whole, the Swift compiler 
> will do whatever is necessary to give you a compound view in standard C 
> layout. Ie. it might copy it into
> 
> 
> +-+-+
> | VBO | EBO |
> +-+-+
> 
> and after the call returns put the VBO and EBO values back where they're 
> supposed to be.
> 
> Does that make sense?

So... It seems to me that shuffling things around like that would have some 
overhead. What are the performance implications here? Is it just a matter of 
profiling our code twice -- once with the type defined in Swift and once with 
it defined in C? I mean presumably the Swift compiler wouldn't interject 
"stuff" between the elements without a reason, but OTOH having smaller types 
means that more of them can fit in cache.

Is this an area where the best answer is "do what works now, and ask again when 
we get to Swift 5/6/etc"?

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

Re: [swift-users] Can I use a tuple to force a certain memory layout?

[David Sweeris via swift-users]

> On Jul 19, 2017, at 20:33, Taylor Swift via swift-users 
>  wrote:
> 
> Many APIs like OpenGL take arrays where the atomic unit is multiple elements 
> long. For example, a buffer of coordinates laid out like 
> 
> :[Float] = [ x1, y1, z1, x2, y2, z2, ... , xn, yn, zn ]
> 
> I want to be able to define in Swift (i.e., without creating and importing a 
> Objective C module) a struct that preserves the layout, so that I can do 
> withMemoryRebound(to:capacity:_) or something similar and treat the buffer as 
> 
> struct Point 
> {
> let x:Float, 
> y:Float, 
> z:Float
> }
> 
> :[Point] = [ point1, point2, ... , pointn ]
> 
> The memory layout of the struct isn’t guaranteed, but will the layout be 
> guaranteed to be in declaration order if I use a tuple inside the struct 
> instead?
> 
> struct Point 
> {
> let _point:(x:Float, y:Float, z:Float)
> 
> var x:Float 
> {
> return self._point.x
> }
> 
> var y:Float 
> {
> return self._point.y
> }
> 
> var z:Float 
> {
> return self._point.z
> }
> }
> 
> This is an ugly workaround, but I can’t really think of any alternatives that 
> don’t involve “import something from Objective C”. I am aware that the 
> implementation of structs currently lays them out in declaration order, but 
> I’m looking for something that’s actually defined in the language.

IIRC, Swift doesn't have a way to get a guaranteed memory layout yet, other 
than defining the type in C (or Obj-C) and importing it.

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

Re: [swift-users] is this a defect in equatable for swift tuples?

[David Sweeris via swift-users]

> On Jul 9, 2017, at 10:06, David Baraff via swift-users 
>  wrote:
> 
> 
>> On Jul 9, 2017, at 8:27 AM, Jens Persson  wrote:
>> 
>> (Also, note that your implementation of == uses lhs === rhs thus will only 
>> return true when lhs and rhs are the same instance of SomeClass.)
> Of course — i threw that in just to make a simple example.
> 
> Followup question: what I really wanted to write was an == operator for a 
> tree:
> 
> // silly tree, useful for nothing
> class Tree : Equatable {
>let rootData:Int
>let children:[(String, Tree)]
> 
>static public func ==(_ lhs:Tree, _ rhs:Tree) {
>   return lhs.rootData == rhs.rootData && 
> lhs.children == rhs.children  // sadly, this doesn’t 
> compile
>}
> }

Right, the `==` func is *defined* for 2-element tuples where both elements 
conform to `Equatable`, but that tuple type doesn't itself *conform* to 
`Equatable`. So the`==` func that's defined on "Array where Element: Equatable" 
can't see it.

We'd need both "conditional conformance" and "tuple conformance" in order for 
that to Just Work.

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

Re: [swift-users] Filling two type parameters with the same type

[David Sweeris via swift-users]

Hmm... I just tried it in a playground, and it works:
struct DistortedNoise<Source, Displacement> {
  let source:Source,
  displacement:Displacement
  
  init(source:Source, displacement:Displacement)
  {
self.source   = source
self.displacement = displacement
  }
  
}
extension DistortedNoise where Source == Displacement {
  init(source:Source)
  {
self.source   = source
self.displacement = source
  }
}
let foo = DistortedNoise(source: 1) // DistortedNoise<Int, Int>
foo.source // 1
foo.displacement // 1

That's with Xcode 9b2, using the default Xcode 9.0 toolchain. With Xcode 8.3.3 
and its default toolchain, the `let foo = ...` line outputs 
"__lldb_expr_2.DistortedNoise<Int, Int>" instead of just "DistortedNoise<Int, 
Int>", but that's just a more... I think the word is "qualified"... name for 
the same thing.

- Dave Sweeris


> On Jul 8, 2017, at 9:39 PM, Zhao Xin <owe...@gmail.com> wrote:
> 
> No, David, it is now allowed.  "error: same-type requirement makes generic 
> parameters 'Source' and 'Displacement' equivalent".
> 
> Zhao Xin
> 
> On Sun, Jul 9, 2017 at 12:35 PM, David Sweeris via swift-users 
> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
> You could try putting that init in an extension "where Source == Displacement"
> 
> > On Jul 8, 2017, at 21:06, Taylor Swift via swift-users 
> > <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
> >
> > I have a type like
> >
> > struct DistortedNoise<Source, Displacement> where Source:Noise, 
> > Displacement:Noise
> > {
> > let source:Source,
> > displacement:Displacement
> >
> > init(source:Source, displacement:Displacement)
> > {
> > self.source   = source
> > self.displacement = displacement
> > }
> >
> > init(source:Source)
> > {
> > self.source   = source
> > self.displacement = source
> > }
> > }
> >
> > and I get the error
> >
> > Compile Swift Module 'Noise' (5 sources)
> > /home/taylor/noise/sources/noise/noise.swift:576:29: error: 'Source' is not 
> > convertible to 'Displacement'
> > self.displacement = source
> > ^~
> >
> > How do I tell Swift that I want the same type fulfilling both Source and 
> > Displacement?
> >
> > ___
> > swift-users mailing list
> > swift-users@swift.org <mailto:swift-users@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-users 
> > <https://lists.swift.org/mailman/listinfo/swift-users>
> ___
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users 
> <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] Filling two type parameters with the same type

[David Sweeris via swift-users]

Oh, I hate that error! If there was ever a time I've wanted to have a 
conversation with the compiler... "yes, mr compiler, I know the same type 
requirement makes them equivalent; that's why I wrote it! Please compile 
anyway."

Which version of the compiler/language are you using?

Sent from my iPhone

> On Jul 8, 2017, at 21:39, Zhao Xin <owe...@gmail.com> wrote:
> 
> No, David, it is now allowed.  "error: same-type requirement makes generic 
> parameters 'Source' and 'Displacement' equivalent".
> 
> Zhao Xin
> 
>> On Sun, Jul 9, 2017 at 12:35 PM, David Sweeris via swift-users 
>> <swift-users@swift.org> wrote:
>> You could try putting that init in an extension "where Source == 
>> Displacement"
>> 
>> > On Jul 8, 2017, at 21:06, Taylor Swift via swift-users 
>> > <swift-users@swift.org> wrote:
>> >
>> > I have a type like
>> >
>> > struct DistortedNoise<Source, Displacement> where Source:Noise, 
>> > Displacement:Noise
>> > {
>> > let source:Source,
>> > displacement:Displacement
>> >
>> > init(source:Source, displacement:Displacement)
>> > {
>> > self.source   = source
>> > self.displacement = displacement
>> > }
>> >
>> > init(source:Source)
>> > {
>> > self.source   = source
>> > self.displacement = source
>> > }
>> > }
>> >
>> > and I get the error
>> >
>> > Compile Swift Module 'Noise' (5 sources)
>> > /home/taylor/noise/sources/noise/noise.swift:576:29: error: 'Source' is 
>> > not convertible to 'Displacement'
>> > self.displacement = source
>> > ^~
>> >
>> > How do I tell Swift that I want the same type fulfilling both Source and 
>> > Displacement?
>> >
>> > ___
>> > 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] Filling two type parameters with the same type

[David Sweeris via swift-users]

You could try putting that init in an extension "where Source == Displacement"

> On Jul 8, 2017, at 21:06, Taylor Swift via swift-users 
>  wrote:
> 
> I have a type like 
> 
> struct DistortedNoise where Source:Noise, 
> Displacement:Noise
> {
> let source:Source,
> displacement:Displacement
> 
> init(source:Source, displacement:Displacement)
> {
> self.source   = source
> self.displacement = displacement
> }
> 
> init(source:Source)
> {
> self.source   = source
> self.displacement = source
> }
> }
> 
> and I get the error 
> 
> Compile Swift Module 'Noise' (5 sources)
> /home/taylor/noise/sources/noise/noise.swift:576:29: error: 'Source' is not 
> convertible to 'Displacement'
> self.displacement = source
> ^~
> 
> How do I tell Swift that I want the same type fulfilling both Source and 
> Displacement?
> 
> ___
> 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] Can I create a Cocoa app that is only a Swift script?

[David Sweeris via swift-users]

> On Jun 22, 2017, at 02:55, tuuranton--- via swift-users 
>  wrote:
> 
> > It is not. The first problem is that there is no
> > value of "/path/to/swift" that will work everywhere.
> 
> 
> Makes sense, but I guess one day macOS will ship with swift in a standard 
> location like /usr/bin/swift so that would no longer be a problem.

It gets distributed as part of Xcode (which is free, but not preloaded on 
anything) or as a download from swift.org or GitHub now. Unless they port iOS's 
playgrounds app to macOS, I'm not sure what would motivate apple to change that 
in the future.

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

Re: [swift-users] Intended behavior or bug in Dictionary's new subscript(_:default:)?

[David Sweeris via swift-users]

> On Jun 17, 2017, at 21:12, Ben Cohen via swift-users  
> wrote:
> 
> In order for this defaulting subscript technique to work as intended, the 
> subscript { get } needs to be called, then the mutation happens, then the 
> subscript { set } writes the mutated value back, including adding it for the 
> first time it the default was needed.
> 
> Reference types, not being value types, skip the write-back part, because 
> they shouldn’t need writing back – they should just get amended in place, 
> because they’re reference types. 
> 
> Except this particular technique is relying on it.
> 
> This is probably worth a bug report, though I’m not sure if there’s an easy 
> fix. The alternative is that Dictionary.subscript(_: default:) be made a 
> mutating get that sets the default if not present, even without the set. 
> There’s downsides to this though: you would no longer be able to use this 
> defaulting subscript with immutable dictionaries, and getting a default value 
> would add it which might be very unexpected.

We could say "extension Dictionary where Value: class", but that'll only fix it 
when the compiler knows `Value` has reference semantics (and lead to even more 
confusion when used in generic functions without the "T: class" part).

Could we check if `Value: class` within the existing setter? Or if that's what 
we already do to skip the write-back, skip the skipping when one of the values 
is nil?

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

Re: [swift-users] swift 4.0 complains/warns about swapping array elements

[David Sweeris via swift-users]

> On May 19, 2017, at 10:10, Edward Connell via swift-users 
>  wrote:
> 
> I just switched to the 5/17 swift 4.0 tool chain on Linux, and I am getting 
> the following complaint when using swap on array elements. Is this warning 
> legitimate because of a copy on write issue? If so, is there some new swap 
> function for array elements? I realize I can turn 1 line into 3 and do the 
> swapping myself, it's just verbose.
> 
> warning: simultaneous accesses to var 'dims', but modification requires 
> exclusive access; consider copying to a local variable
> swap([lastIndex], [lastIndex-1])

Looks like it got changed to "swapAt": 
https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md

Hope that helps,
- Dave Sweeris ___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] How to reference a generic function when a concrete version also exists?

[David Sweeris via swift-users]

> On May 2, 2017, at 4:39 PM, Nevin Brackett-Rozinsky via swift-users 
>  wrote:
> 
> If I write a generic function like this:
> 
> func f(_ x: T) { print("Generic: \(x)") }
> 
> I can pass it to another function like this:
> 
> func g(_ fn: (Int) -> Void) { fn(0) }
> g(f)// Prints “Generic: 0”
> 
> However if I *also* write a non-generic function like this:
> 
> func f(_ x: Int) { print("Int: \(x)") }
> 
> Then when I make the same call as before:
> 
> g(f)// Prints “Int: 0”
> 
> It passes in the new, non-generic version.
> 
> Is there something I can do, with both versions of f defined, to pass the 
> generic f into g?

Not that I know of. Once the code path gets to g(), the compiler knows that the 
function is specifically an (Int)->Void, as opposed to the generic (T)->Void, 
and it’ll always go for the most specific overload. AFAIK, anyway.

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

Re: [swift-users] Any way to declare a method that suppresses the string interpolation warning?

[David Sweeris via swift-users]

> On Apr 23, 2017, at 23:23, Rick Mann via swift-users  
> wrote:
> 
> 
>> On Apr 22, 2017, at 12:23 , Saagar Jha  wrote:
>> 
>> 
>> Saagar Jha
>> 
>>> On Apr 21, 2017, at 04:35, Rick Mann via swift-users 
>>>  wrote:
>>> 
>>> I have a debugLog() method that looks like this:
>>> 
>>> func
>>> debugLog(_ inMsg: T, _ inFile : String = #file, _ inLine : Int = #line)
>> 
>> Well, for starters, I don’t see why you need to make this function generic. 
>> Why not make inMsg an `Any?`?
> 
> So I can write debugLog()
> 
>> 
>>> {
>>>let df = DateFormatter()
>>>df.dateFormat = "-MM-dd HH:mm:ss.SSS"
>>>let time = df.string(from: Date())
>>>
>>>let file = (inFile as NSString).lastPathComponent
>>>print("\(time) \(file):\(inLine)\(inMsg)”)
>> 
>> Try \(inMsg ?? “nil”).
> 
> No, this is missing the point. I don't want to have to write this everywhere. 
> I just want to tell the compiler not to issue the warning in these cases, 
> much in the way you can tell the compiler to check printf format specifiers.

IIRC, Swift doesn't include a mechanism for suppressing warnings because we 
don't want to encourage different "dialects" of the language. The best I can 
offer for ignoring it is something like:
extension CustomStringConvertible {
  // for "pretty print"
  var pp: String {
return self.description
  }
}
extension Optional where Wrapped: CustomStringConvertible {
  var pp: String {
return self?.description ?? "nil"
  }
}
(written on my phone... might contain errors)

That way at least it's quicker to type, cleaner to read, and the code is the 
same between Optional and non-Optional types.

- Dave Sweeris


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

Re: [swift-users] Swift 3.1 String(

[David Sweeris via swift-users]

> On Apr 5, 2017, at 07:49, Rien via swift-users  wrote:
> 
> 
>> 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”)”)

I thought we couldn't nest quotes. Has that changed (because that would be 
fantastic)?

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

Re: [swift-users] [swift-build-dev] Importing C system libraries

[David Sweeris via swift-users]

> On Mar 28, 2017, at 1:58 AM, Rien via swift-build-dev 
>  wrote:
> 
> 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).

Since you mentioned it… :-D

Using two monitors is a whole new world, and I cannot recommend it highly 
enough. Three is an improvement over two, but not by nearly the same margin as 
two is to one. Four is, well, I suppose better than leaving a monitor laying 
around and not doing anything… I've tried stretching my Xcode window really 
tall, but the bezels are too disruptive for me. I’ve heard more than one person 
claim that 1x 21:9 monitor is just as good as 2x 16:9/16:10 monitors (maybe 
better, because the two “screens” don’t have to be the same size anymore), but 
I haven’t had a chance to try one out yet.

> 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.

Yeah, if Xcode were open-source, I’d be working on SwiftPM integration. Hmm… 
Maybe SwiftPM can detect if a .xcodeproj file already exists and copy any 
custom settings from there before writing the new one? That might not be too 
hard, depending on how complicated those files are.

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

Re: [swift-users] Why does this leak?

[David Sweeris via swift-users]

Could you call the supposedly leaky code a few million times and look at memory 
usage to see if there's actually a leak?

- Dave Sweeris 

> On Mar 27, 2017, at 13:31, Rick Aurbach via swift-users 
>  wrote:
> 
> Okay, I downloaded the latest Xcode from the developer site. (The download 
> page said it was 8.3beta5, but the version info called it 8.3 (8E161).)
> 
> So I put the use of the enum back into my code and profiled it again. (Please 
> refer to my original post for the Case 1 code that I’m testing here.)
> 
> According to the Leaks Instrument, there is still a leak (just one 32-byte 
> block, rather than two) coming from the call to prepare.
> 
> Unless I’m missing something REALLY basic here, using the enum as in my 
> original post should not leak. (Right??) So either there is a compiler issue 
> (still present in the compiler version of Xcode 8E161) or there is an issue 
> in the Leaks Instrument (still present in the latest Xcode).
> 
> This is frustrating, because I don’t want to release a product with known 
> leaks, but I don’t really know at this point whether I have one or whether 
> I’m just seeing an artifact. Suggestions??
> 
> Cheers,
> 
> Rick Aurbach
> 
>>> On Mar 27, 2017, at 3:01 AM, Alex Blewitt  wrote:
>>> 
>>> 
>>> On 26 Mar 2017, at 18:43, Rick Aurbach via swift-users 
>>>  wrote:
>>> 
>>> I have a situation where I have a leak that I do not understand. I would be 
>>> very grateful if someone could explain it to me and offer an idea of how I 
>>> can make the pattern work without leaking:
>> 
>> How are you determining that this is leaking? There was an issue in Xcode 
>> where the 'leaks' detector was unable to introspect the memory layout of a 
>> Swift object containing an enum stored property and incorrectly flagging 
>> other such reachable objects as leaks. If that's the case, do you still see 
>> the same behaviour flagged in the latest Xcode?
>> 
>> Alex
>> 
> 
> ___
> 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] Quick Question about ExpressibleByStringLiteral

[David Sweeris via swift-users]

Great! Thanks, Andrew :-)

- Dave Sweeris

> On Mar 9, 2017, at 6:00 PM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> Andrew Bennett is two steps ahead of you. :-) 
> https://github.com/apple/swift/pull/7125 
> <https://github.com/apple/swift/pull/7125>
> 
> Jordan
> 
>> On Mar 9, 2017, at 17:59, David Sweeris via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> If my type doesn’t know/care about the difference between a normal “String" 
>> and an “ExtendedClusterScalarGraphemeLiteralUnicodeTypeCluster” (or whatever 
>> those other literal types are called), is there anything wrong with doing 
>> this?
>> public protocol EasilyExpressibleByStringLiteral : 
>> ExpressibleByStringLiteral {
>> typealias StringLiteralType = String
>> }
>> extension EasilyExpressibleByStringLiteral where StringLiteralType == String 
>> {
>> public init(unicodeScalarLiteral value: String.UnicodeScalarLiteralType) 
>> {
>> self.init(stringLiteral: String(describing: value))
>> }
>> public init(extendedGraphemeClusterLiteral value: 
>> String.ExtendedGraphemeClusterLiteralType) {
>> self.init(stringLiteral: String(describing: value))
>> }
>> }
>> because then I only have to write the one init function:
>> public struct MyType : EasilyExpressibleByStringLiteral {
>> public init(stringLiteral value: StringLiteralType) {...}
>> }
>> and the compiler will stop complaining about my type not conforming to the 
>> other two protocols. Because I’ve scanned the docs, and I can’t even figure 
>> out how to create an ExtendedGraphemeClusterLiteral, let alone come up with 
>> a reason why I’d want to treat it differently than a regular String when 
>> using it to initialize an instance of MyType.
>> 
>> - Dave Sweeris
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto: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] Quick Question about ExpressibleByStringLiteral

[David Sweeris via swift-users]

If my type doesn’t know/care about the difference between a normal “String" and 
an “ExtendedClusterScalarGraphemeLiteralUnicodeTypeCluster” (or whatever those 
other literal types are called), is there anything wrong with doing this?
public protocol EasilyExpressibleByStringLiteral : ExpressibleByStringLiteral {
typealias StringLiteralType = String
}
extension EasilyExpressibleByStringLiteral where StringLiteralType == String {
public init(unicodeScalarLiteral value: String.UnicodeScalarLiteralType) {
self.init(stringLiteral: String(describing: value))
}
public init(extendedGraphemeClusterLiteral value: 
String.ExtendedGraphemeClusterLiteralType) {
self.init(stringLiteral: String(describing: value))
}
}
because then I only have to write the one init function:
public struct MyType : EasilyExpressibleByStringLiteral {
public init(stringLiteral value: StringLiteralType) {...}
}
and the compiler will stop complaining about my type not conforming to the 
other two protocols. Because I’ve scanned the docs, and I can’t even figure out 
how to create an ExtendedGraphemeClusterLiteral, let alone come up with a 
reason why I’d want to treat it differently than a regular String when using it 
to initialize an instance of MyType.

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

Re: [swift-users] Anyone else having trouble getting swift to build?

[David Sweeris via swift-users]

Yep. Do I need to uninstall 8.2, though? I hadn't thought to try that until 
just now.

Sent from my iPhone

> On Mar 5, 2017, at 15:10, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> 
> Shot in the dark: are you using the latest Xcode beta?
> 
>> On Sun, Mar 5, 2017 at 3:03 PM, David Sweeris via swift-users 
>> <swift-users@swift.org> wrote:
>> In particular, the "utils/build-script -x” will fail with 84 errors on my 
>> system. As best as I can tell, they're all/mostly linker errors because the 
>> correct .dylib files aren't being created (not sure why there wouldn’t be 
>> errors from that, but I don’t see any)? Is there an option to not require 
>> the build to succeed before creating the project file? At least that way I 
>> could get a better sense of where the errors are coming from.
>> 
>> (FWIW, as far as I can tell, all the build-script options are failing, not 
>> just -x)
>> 
>> - Dave Sweeris
>> 
>> 
>> 
>> ___
>> 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] Anyone else having trouble getting swift to build?

[David Sweeris via swift-users]

In particular, the "utils/build-script -x” will fail with 84 errors on my 
system. As best as I can tell, they're all/mostly linker errors because the 
correct .dylib files aren't being created (not sure why there wouldn’t be 
errors from that, but I don’t see any)? Is there an option to not require the 
build to succeed before creating the project file? At least that way I could 
get a better sense of where the errors are coming from.

(FWIW, as far as I can tell, all the build-script options are failing, not just 
-x)

- Dave Sweeris


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

Re: [swift-users] question on generics

[David Sweeris via swift-users]

> On Feb 22, 2017, at 16:08, Dave Reed via swift-users  
> wrote:
> 
> I suspect this can't be done (at least not right now), but wanted to check.
> 
> I'd like to declare a class as a generic that meets a protocol and is also a 
> subclass of some specific type.
> 
> Something like class Foo (i.e., the T must 
> be both a NSManagedObject or subclass of it and conform to SomeProtocol).
> 
> Is this possible?

Yep
class Foo  where T:  SomeProtocol {...}
should work fine (although I'm not in front of my computer to double check)

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

Re: [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[David Sweeris via swift-users]

Sent from my iPhone

> On Feb 19, 2017, at 13:41, Lane Schwartz via swift-users 
>  wrote:
> 
> Hi all,
> 
> I'm sure there are good reasons for this switch. Personally, I strongly 
> prefer email lists to forums. 
> 
> This move will make it harder for me to participate in future discussions and 
> I will be less inclined to take the effort to sign into a forum do so.
> 
> Is there a plan to enable an integrated mailing list functionality so that 
> those of us who prefer that modality can continue to participate via email? 
> Other forum software that I've been asked to use in the past (sorry, I can't 
> remember the name) had this functionality, and it made a huge difference for 
> me.

AFAIK, the plan is to not switch unless the mailing list functionality can be 
kept.

(I'm not an official source or anything, that's just the impression I got)

- Dave Sweeris 


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

Re: [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[David Sweeris via swift-users]

> On Feb 9, 2017, at 09:30, Matthew Johnson via swift-users 
>  wrote:
> 
> 
>>> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users 
>>>  wrote:
>>> 
>>> 
>>> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users 
>>>  wrote:
>>> 
>>> I would prefer http://www.fudforum.org/ that has good mailing list support, 
>>> too.
>> 
>> Well, we appear to have completely opposite opinions on UI/usability. I took 
>> a look at fudforum and yeah, to my eyes it exemplifies the awful clutter 
>> that’s been a hallmark of web forums since before PHPBB. There’s so much 
>> visual noise it’s very hard to parse or to find anything. Clearly designed 
>> by a coder with a big hammer named “”. I’m not a UI designer, but 
>> I’ve worked extensively with UI designers (I spent 15 years at Apple working 
>> on stuff like iChat and AppleScript) so I think I have some grounding in the 
>> field.
>> 
>> I do believe, though, that whatever solution swift.org switches to needs to 
>> have good email support. That way the people who hate the web UI, or who 
>> just don’t prefer to use the web for discussions, can keep using email as we 
>> do today. This is perfectly feasible to do; again, groups.io is a good 
>> example. 
>> 
>> Here my concern is that I have not found a way to configure Discourse to 
>> make its email notifications work well as a substitute for a mailing list. I 
>> have admin privileges on a Discourse installation run by my employer, so 
>> I’ve looked through the entire admin UI for ways to improve the emails, and 
>> some of the problems don’t seem fixable by tweaking settings.
>> 
>> At this point I’m going to shut up because it sounds like the decision has 
>> been made, and I don’t want to contribute to further bike-shedding.
> 
> I’ve been mostly silent in this conversation largely because I didn’t realize 
> it was leading up to a formal decision.  I wish it would have followed the 
> proposal process so it was clear to everyone that a decision was being 
> considered and this was our chance to offer input.  
> 
> I really like the experience of participating in the community via email.  If 
> I knew a decision was being seriously considered I would have taken a closer 
> look at Discourse and likely offered more input.  I will be disappointed if 
> the experience of participating is not at least as good as it is using email.

I'm pretty sure that Discourse's mailing list support is why so many people 
suggested it.

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

Re: [swift-users] Implicitly capture a mutating self

[David Sweeris via swift-users]

> On Dec 16, 2016, at 15:54, Richard Wei via swift-users 
>  wrote:
> 
> Thanks. That’s true, but there are cases (like making BLAS calls) where I 
> have to nest more than 4 `withUnsafeMutable…` closures. It’s safe by really 
> clumsy. I just wish there were a cleaner way that looks like the do-notation 
> in Haskell or for-notation in Scala.

You might be able to do something with wrapper functions or operators. As long 
as you tell the compiler to always inline them, I don't think that'd cause any 
performance issues.

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

Re: [swift-users] Decimal to Double?

[David Sweeris via swift-users]

> On Nov 28, 2016, at 13:43, Joe Groff via swift-users  
> wrote:
> 
> 
>> On Nov 28, 2016, at 11:42 AM, Nevin Brackett-Rozinsky 
>>  wrote:
>> 
>> On Mon, Nov 28, 2016 at 2:21 PM, Joe Groff via swift-users 
>>  wrote:
>> ExpressibleByFloatLiteral uses a binary float initial value and so doesn't 
>> guarantee decimal accuracy
>> 
>> That seems like a flaw in ExpressibleByFloatLiteral that should be fixed.
>> 
>> Did anyone ever submit a proposal following the discussion in 
>> “[swift-evolution] Allow FloatLiteralType in FloatLiteralConvertible to be 
>> aliased to String” where somebody—*runs to check*…oh it was you!—described 
>> the proper solution?
> 
> Fixing ExpressibleByFloatLiteral has come up several times, but nobody's 
> formally written up the proposal AFAIK.

I'm in the middle of moving, or I'd do it.

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

Re: [swift-users] Decimal to Double?

[David Sweeris via swift-users]

Sent from my iPhone
> On Nov 28, 2016, at 13:21, Joe Groff  wrote:
> 
> It really shouldn't be, since ExpressibleByFloatLiteral uses a binary float 
> initial value and so doesn't guarantee decimal accuracy. I'd recommend using 
> init(mantissa:exponent:isNegative:) instead, and minimizing any conversions 
> between Double and Decimal.

That's what I was worried about... What's the "correct" way to express a 
literal as a Decimal, then? Use a string literal, `"2.1"`, instead of a float 
literal, `2.1`?

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

Re: [swift-users] Workaround for generics not currently supporting conditional conformance to a protocol

[David Sweeris via swift-users]

> On Nov 16, 2016, at 16:35, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> 
>>> On Nov 16, 2016, at 7:35, David Sweeris via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> 
>>> On Nov 15, 2016, at 11:55 PM, Howard Lovatt <howard.lov...@gmail.com> wrote:
>>> 
>>> @Dave,
>>> 
>>> How do I write that though.
>>> 
>>> I can't write:
>>> 
>>> extension Array: Equatable {
>>> static func ==(lhs: Array, rhs: Array) -> Bool {
>>> let size = lhs.count
>>> precondition(rhs.count == size, "The arrays must be the same 
>>> length")
>>> for i in 0 ..< size {
>>> if (lhs[i] as! Equatable) != (rhs[i] as! Equatable) {
>>> return false
>>> }
>>> }
>>> return true
>>> }
>>> }
>>> 
>>> Because I can't cast to an Equatable, because Equatable uses Self.
>>> 
>>> Am I missing something?
>>> 
>>>  -- Howard.
>>> 
>>>   -- Howard.
>>> 
>>>> On 16 November 2016 at 16:35, David Sweeris <daveswee...@mac.com> wrote:
>>>> 
>>>> > On Nov 15, 2016, at 21:39, Howard Lovatt via swift-users 
>>>> > <swift-users@swift.org> wrote:
>>>> >
>>>> > Hi All,
>>>> >
>>>> > Does anyone have a good workaround for generics not currently supporting 
>>>> > conditional conformance to a protocol. As stated in the Generics 
>>>> > Manifesto something like this would be nice:
>>>> >
>>>> >   extension Array: Equatable where Element: Equatable {
>>>> > static func ==(lhs: Array, rhs: Array) -> Bool { ... }
>>>> > }
>>>> >
>>>> > But I would currently write a wrapper, something like:
>>>> >
>>>> > struct ArrayE {
>>>> > var elements: [T]
>>>> > }
>>>> > extension ArrayE: Equatable {
>>>> > static func ==(lhs: ArrayE, rhs: ArrayE) -> Bool { ...  }
>>>> > }
>>>> >
>>>> > This can get unwieldy when there are a lot of conditional protocol 
>>>> > extensions required, i.e. wrappers round wrappers.
>>>> >
>>>> > Is there a better way?
>>>> >
>>>> > Thanks for any tips,
>>>> >
>>>> >   -- Howard.
>>>> > ___
>>>> > swift-users mailing list
>>>> > swift-users@swift.org
>>>> > https://lists.swift.org/mailman/listinfo/swift-users
>>>> 
>>>> Can you make Array conform to Equatable for any T and then in the == 
>>>> function, if T conforms to Equatable loop the Arrays to check if they're 
>>>> equal, and if it doesn't conform just return false?
>>>> 
>>>> I mean, it's still "wrong", but at least you won't get any false positives.
>>>> 
>>>> - Dave Sweeris
>>> 
>> 
>> You are correct. The work-around is to use two extensions and overload the 
>> == operator:
>> 
>> extension Array: Equatable {
>> public static func == (lhs: Array, rhs: Array) -> Bool {
>> return false
>> }
>> }
>> extension Array where Element : Equatable {
>> public static func == (lhs: Array, rhs: Array) -> Bool {
>> return lhs.count == rhs.count && {
>> for i in 0..> if lhs[i] != rhs[i] {
>> return false
>> }
>> }
>> return true
>> }()
>> }
>> }
>> 
>> It works in playgrounds (Xcode 8.1 (8B62)), but I haven’t tested it outside 
>> a few trivial cases.
> 
> This does not work. The == dispatch for Arrays is static in this case, not 
> dynamic. You can test this by writing something generic on Equatable.
> 
> func same(_ x: T, _ y: T) -> Bool { return x == y }
> print(same([1], [2]))
> 
> Rule of thumb: overloads are resolved statically, protocol requirements are 
> invoked dynamically. You cannot get dynamic behavior out of just overloads, 
> ever.
> 
> I don't think there's a way to get this behavior today, unfortunately.

Aw, nuts! I forgot to try adding another level of, um... genericititty?

Yeah, I think you're right... On the plus side, when conditional conformance 
hits the wrapper structs can be backed out just by searching your project for 
their name and replacing it with "Array" (or "Set", etc), right?

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

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

[David Sweeris via swift-users]

> On Nov 14, 2016, at 16: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.

Odd... Perhaps the compiler is convinced the result of the *** operation needs 
to be an Int? Dunno why that would be, though.

What happens if you split it up into two statements?

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

Re: [swift-users] Optimising Set comparisons

[David Sweeris via swift-users]

> On Nov 13, 2016, at 1:58 PM, Nial Giacomelli via swift-users 
>  wrote:
> 
> Using Swift 3 I have a function that's called extremely frequently and is 
> appearing regularly in Profiler runs. The function takes two Set 
> instances and simply attempts to determine whether all items from Set A are 
> present in Set B (it's important to note that Set B may well contain 
> additional items).
> 
> I've attempted to approach the problem in two ways:
> 
> let diff = a.subtracting(b)
> guard diff.count == 0 else { return false }
> 
> And also by simply iterating over the contents of Set A, like so:
> 
> for item in a {
>   if !b.contains(item) {
>   return false
>   }
> }
> 
> Both ultimately end up spending the majority of their time in 
> String._compareDeterministicUnicodeCollaton(String) -> Int. Which makes 
> sense, given what I'm doing - but ideally I'd like to come up with a more 
> efficient way of performing the above check. Swift's String representation is 
> incredibly robust, but for my needs the strings could be adequately 
> represented in ASCII encoding. I've also considered storing and comparing the 
> hashValue of the strings, to speed up comparisons...
> 
> Hopefully this is an acceptable question for this mailing list. I'm aware 
> that this may not be a Swift-specific question and could well be solved with 
> a more efficient data structure or approach, but I'd really appreciate some 
> input from more experienced Swift developers :-)

How often do the sets change? And where do you get them from? I’m wondering, if 
there’s enough time between when you get the strings and when you need to know 
if setA is a subset of setB, could you somehow compute the answer 
asynchronously in a background thread or something? Strictly speaking it 
wouldn't be any less work, but if you can move it to where you’re waiting for 
user input or something you’ll probably get your answer sooner.

Regarding how to get the answer using less work in the first place, I think 
you’re doing a tiny bit of extra work — just some allocation overhead, really — 
by calculating the set difference and checking that its count == 0, rather than 
just checking if a.isSubset(of: b). Beyond that, I’m not really sure… You might 
be able to do something with the strings’ hash values. I mean, I don’t know if 
they really “work like that” (I’m quite foggy on how hash values are calculated 
and exactly what they’re suitable for… this might be a horrible idea), but if 
they do, comparing hash values (Ints) will definitely be faster than comparing 
Strings. I did some quick’n’dirty testing on my machine with some code very 
much like:
let setA: Set = ["some", "set", "of", "random", "strings"]
let setB: Set = ["some", "other", "set", "of", "strings"]
let hashedA = Set(setA.map{$0.hashValue})
let hashedB = Set(setB.map{$0.hashValue})
setA.isSubset(of: setB)
hashedA.isSubset(of: hashedB)

The actual execution of hashedA.isSubset(of: hashedB) seems to be very roughly 
2x faster than setA.isSubset(of: setB). However, if you include the overhead of 
calculating them, using hash values drops to about 5x slower. So unless you’d 
be reusing the hashed values a lot or something, I think you’re already doing 
about the least amount of work I can think of.

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

Re: [swift-users] Reflection in Swift 3?

[David Sweeris via swift-users]

> On Nov 13, 2016, at 1:55 AM, Rick Mann  wrote:
> 
> 
>> On Nov 12, 2016, at 22:47 , David Sweeris  wrote:
>> 
>> 
>>> On Nov 13, 2016, at 00:38, Rick Mann via swift-users 
>>>  wrote:
>>> 
>>> So, it seems there's still no way to do something like instantiate a class 
>>> given only its name (as a String)?
>>> 
>>> In my situation, I have a number of subclasses (or protocol 
>>> implementations), which parallel some other class hierarchy. I need to 
>>> dynamically create one based on the name of another. I don't want the 
>>> latter classes to "know" anything about the former.
>> 
>> Not that I know of... If this is all your code, can you fake it by switching 
>> over the type's name?
> 
> Yeah, it just happens in a few places, would be nice to write the code once 
> and then just ensure classes exist. I know I could do it subclassing 
> NSObject, but Swift really ought to have proper reflection.

Reflection is on the todo list (although I can’t recall if it’s in-scope for 
Swift 4).

There’s also the possibility of putting the names of the classes you want to 
instantiate into an enum. In fact, if all the classes in question have a common 
superclass, you could this:
class MyAwesomeSuperClass { required init() {} }
class MyAwesomeSubClass : MyAwesomeSuperClass {}
class Whatever : MyAwesomeSuperClass {}
class Etc : Whatever {}
enum ClassNames : String {
//Unfortunately the value of each case has to be a literal, so
//you can’t just say `case etc = "\(Etc.self)"`
case myAwesomeSuperClass = "MyAwesomeSuperClass"
case myAwesomeSubClass = "MyAwesomeSubClass"
case whatever = "Whatever"
case etc = "Etc"
init(_ instance: MyAwesomeSuperClass) { self = ClassNames.init(rawValue: 
"\(type(of: instance))")! }
init(_ type: MyAwesomeSuperClass.Type) { self = ClassNames.init(rawValue: 
"\(type)")! }
var type: MyAwesomeSuperClass.Type {
switch self {
case .myAwesomeSuperClass:  return MyAwesomeSuperClass.self
case .myAwesomeSubClass:return MyAwesomeSubClass.self
case .whatever: return Whatever.self
case .etc:  return Etc.self
}
   }
}
var etc = Etc()
var className = ClassNames(etc)
var newEtc = className.type.init()

The same trick works if all the types in question conform to the same protocol, 
too:
protocol MyAwesomeProtocol {
init()
func toIntMax() -> IntMax
}
extension Int : MyAwesomeProtocol {}
struct Five : MyAwesomeProtocol { func toIntMax() -> IntMax { return 5 } }
enum ProtocolNames : String {
case five = "Five"
case int = "Int"
init(_ instance: MyAwesomeProtocol) { self = ProtocolNames.init(rawValue: 
"\(type(of: instance))”)! }
init(_ type: MyAwesomeProtocol.Type) { self = ProtocolNames.init(rawValue: 
"\(type)")! }
var type: MyAwesomeProtocol.Type {
switch self {
case .five: return Five.self
case .int:  return Int.self
}
}
}
var five = Five()
var fiveName = ProtocolNames(five)
var newFive = fiveName.type.init()

Either way, though, you’ll have to do something like if let nf = newFive as? 
Int {…} if you want to use any functionality that isn’t explicitly in the 
superclass or protocol.

It certainly involves some boilerplate code, but it also has the advantages of 
validating the name before you try to use it and ensuring that any switch 
statements can actually handle all the classes. 

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

Re: [swift-users] Reflection in Swift 3?

[David Sweeris via swift-users]

> On Nov 13, 2016, at 00:38, Rick Mann via swift-users  
> wrote:
> 
> So, it seems there's still no way to do something like instantiate a class 
> given only its name (as a String)?
> 
> In my situation, I have a number of subclasses (or protocol implementations), 
> which parallel some other class hierarchy. I need to dynamically create one 
> based on the name of another. I don't want the latter classes to "know" 
> anything about the former.

Not that I know of... If this is all your code, can you fake it by switching 
over the type's name?

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

Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[David Sweeris via swift-users]

I don't know what you mean by "naked function", but you'd request it by 
starting a thread on swift evolution (which I would encourage you to do).

- Dave Sweeris

> On Aug 15, 2016, at 17:36, Rick Mann <rm...@latencyzero.com> wrote:
> 
> Well, even C++ requires some amount of run time. On a larger MCU, the runtime 
> shouldn't be a problem at all. What I want to do is minimize the amount of OS 
> I have to implement. For example, using newlib 
> (https://sourceware.org/newlib/), I can stub out 20-odd functions, and 
> everything gets statically linked into a monolithic block of code that is a 
> combination of my code, the runtime, and those 20-odd function stubs. A 
> special chunk of code, usually containing assembly language, ensures the 
> processor and MMU are properly set up just after boot, and you're off to the 
> races.
> 
> I imagine there will be additional burden to support threading and GCD (which 
> would be nice to have). But before that, supporting synchronization and 
> interrupt routines.
> 
> Ah, interrupt routines. Is there any way to mark a function as "naked" in 
> Swift? How would I request that feature?
> 
>> On Aug 11, 2016, at 21:46 , Slava Pestov <spes...@apple.com> wrote:
>> 
>> Even if you take care not to create class instances, the compiler emits many 
>> calls to runtime functions to implement features such as generics, casts and 
>> existentials. It is possible to write code where a large number of runtime 
>> calls are optimized away, but I don’t think they can be eliminated 
>> completely.
>> 
>> If anyone is interested in taking this on as a community project, it would 
>> be a fair amount of work, but I think the first step could be to add 
>> compiler flags where calls to runtime functions become diagnostics. Again 
>> though, I’m not sure how much effort it would take to eliminate them 
>> completely.
>> 
>> Slava
>> 
>>> On Aug 10, 2016, at 3:28 AM, David Sweeris via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> There's definitely a runtime, but I *think* you can avoid actually using it 
>>> by being very careful with your data structures. ARC means that classes 
>>> obviously trigger it, and I think it *might* be involved resizing arrays 
>>> and strings (they do some tricks behind the scenes, but I can't remember 
>>> what).
>>> 
>>> So... only use structs and don't resize anything? I'm not sure... I think 
>>> there might be some cases where protocols or indirect enums get stored as 
>>> references, and that might involve the runtime as well.
>>> 
>>> Maybe you should go over to the evolution list and suggest a "no runtime" 
>>> compiler flag or source code annotation, which disallows anything which 
>>> would use the runtime. I believe there could be advantages outside of 
>>> running on bare-metal, since you could use it to get the compiler to yell 
>>> at you for doing overhead-inducing stuff in a loop, for example. 
>>> 
>>> Anyway, best of luck :-)
>>> 
>>> - Dave Sweeris
>>> 
>>>> On Aug 9, 2016, at 15:10, Rick Mann via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> 
>>>> Is it possible to use Swift for bare-metal programming on embedded 
>>>> devices? These devices usually have memory-mapped registers that are read 
>>>> and written to affect the operation of the device. Some can be quite small 
>>>> (e.g. 8-bit registers, simple single physical memory address space), and 
>>>> others quite robust (full 32- or 64-bit machines with MMUs, etc.).
>>>> 
>>>> But bare metal development for all of them starts with emitting code with 
>>>> "raw" packaging (no Mach or ELF headers, etc.), and the ability to read 
>>>> and write specific memory addresses.
>>>> 
>>>> For the smaller devices, runtime library overhead is a concern (mostly due 
>>>> to code size). Is it possible to write swift code with no runtime library? 
>>>> I think this is possible in Rust (came up on another list).
>>>> 
>>>> Most such development is done in C, and there is always some form of 
>>>> library to take on some of the standard library tasks and stub out basic 
>>>> IO, as well as filling in gaps for larger variable sizes not directly 
>>>> supported by the hardware.
>>>> 
>>>> I imagine there's some runtime support for ARC, although maybe that's 
>>>> handled entirely 

Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[David Sweeris via swift-users]

There's definitely a runtime, but I *think* you can avoid actually using it by 
being very careful with your data structures. ARC means that classes obviously 
trigger it, and I think it *might* be involved resizing arrays and strings 
(they do some tricks behind the scenes, but I can't remember what).

So... only use structs and don't resize anything? I'm not sure... I think there 
might be some cases where protocols or indirect enums get stored as references, 
and that might involve the runtime as well.

Maybe you should go over to the evolution list and suggest a "no runtime" 
compiler flag or source code annotation, which disallows anything which would 
use the runtime. I believe there could be advantages outside of running on 
bare-metal, since you could use it to get the compiler to yell at you for doing 
overhead-inducing stuff in a loop, for example. 

Anyway, best of luck :-)

- Dave Sweeris

> On Aug 9, 2016, at 15:10, Rick Mann via swift-users  
> wrote:
> 
> Is it possible to use Swift for bare-metal programming on embedded devices? 
> These devices usually have memory-mapped registers that are read and written 
> to affect the operation of the device. Some can be quite small (e.g. 8-bit 
> registers, simple single physical memory address space), and others quite 
> robust (full 32- or 64-bit machines with MMUs, etc.).
> 
> But bare metal development for all of them starts with emitting code with 
> "raw" packaging (no Mach or ELF headers, etc.), and the ability to read and 
> write specific memory addresses.
> 
> For the smaller devices, runtime library overhead is a concern (mostly due to 
> code size). Is it possible to write swift code with no runtime library? I 
> think this is possible in Rust (came up on another list).
> 
> Most such development is done in C, and there is always some form of library 
> to take on some of the standard library tasks and stub out basic IO, as well 
> as filling in gaps for larger variable sizes not directly supported by the 
> hardware.
> 
> I imagine there's some runtime support for ARC, although maybe that's handled 
> entirely in the compilation phase?
> 
> Anyway, I'd appreciate someone more knowledgable letting me know if this is 
> something I should experiment with. Thanks!
> 
> -- 
> 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] Protocol with instance var that's set on construction, otherwise read-only

[David Sweeris via swift-users]

Oh, it's a computed property! Got it, I thought you meant its value was 
computed in the init and never changed again.

Sent from my iPhone

> On Aug 2, 2016, at 19:01, Rick Mann  wrote:
> 
> It complains if I make it a let because computed properties must be var. 
> Because it's a protocol, it can't be stored (even though it can be stored in 
> the conforming type).
> 
> If I make it { get }, I can't set it in the extensions init() method.
> 
> I guess I could make it private set (not sure of the syntax for that), but it 
> still doesn't have let semantics.
> 
>> On Aug 2, 2016, at 16:28 , David Sweeris  wrote:
>> 
>> If I understand things correctly, you *can* make uuid a let because you’re 
>> allowed to set them (once) during init functions.
>> 
>> - Dave Sweeris
>> 
>>> On Aug 2, 2016, at 6:22 PM, Rick Mann via swift-users 
>>>  wrote:
>>> 
>>> I'm trying to define a protocol that has a read-only, immutable member 
>>> "uuid" that can be set in the init() method, but I'm having trouble. I have 
>>> this:
>>> 
>>> protocol
>>> Element
>>> {
>>>  var uuid : { get }
>>> }
>>> 
>>> extension
>>> Element
>>> {
>>>  init(...)
>>>  {
>>>self.uuid = ...
>>>  }
>>> }
>>> 
>>> I can't make it let, because they're computed.
>>> 
>>> I'm realizing from other stuff that I really can't have the init(...) 
>>> method in the extension, anyway. But I'd really like to be able to specify 
>>> a let member in the protocol. What's the best way to have that effect?
>>> 
>>> In my semantics, an Element has a uniquely-assigned uuid. It might be 
>>> generated when the object is instantiated, or it might be deserialized from 
>>> disk, but once that's done, it can never change. How do I express that?
>>> 
>>> Thanks,
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> ___
>>> 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] Protocol with instance var that's set on construction, otherwise read-only

[David Sweeris via swift-users]

If I understand things correctly, you *can* make uuid a let because you’re 
allowed to set them (once) during init functions.

- Dave Sweeris

> On Aug 2, 2016, at 6:22 PM, Rick Mann via swift-users  
> wrote:
> 
> I'm trying to define a protocol that has a read-only, immutable member "uuid" 
> that can be set in the init() method, but I'm having trouble. I have this:
> 
> protocol
> Element
> {
>var uuid : { get }
> }
> 
> extension
> Element
> {
>init(...)
>{
>   self.uuid = ...
>}
> }
> 
> I can't make it let, because they're computed.
> 
> I'm realizing from other stuff that I really can't have the init(...) method 
> in the extension, anyway. But I'd really like to be able to specify a let 
> member in the protocol. What's the best way to have that effect?
> 
> In my semantics, an Element has a uniquely-assigned uuid. It might be 
> generated when the object is instantiated, or it might be deserialized from 
> disk, but once that's done, it can never change. How do I express that?
> 
> Thanks,
> 
> -- 
> 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] Why can't structs inherit from other structs?

[David Sweeris via swift-users]

> On Aug 2, 2016, at 4:03 AM, Tino Heth via swift-users  
> wrote:
> 
> There is no fundamental reason to disallow struct inheritance, and I started 
> a pitch where afair one member of core agreed it would be useful — I hope 
> there is time to add it in the next year.
> There is, however, a fundamental problem with struct polymorphism:
> As soon as you add members, you loose compatibility (a Point3D: Point2D can't 
> be stored or passed where its parent is expected), and when you cross module 
> borders, there might be issues as well.
> Struct and class have to behave different in inheritance, and to disallow 
> struct subtyping completely is just the easiest solution.
> Imho it's definitely not the best solution, as it forces you to use classes 
> whenever you want to use inheritance (I don't think that composition is 
> superior in general).
> It could be even possible to create structs that inherit from classes and 
> vice versa.

I thought the problem with struct polymorphism (specifically the stack size 
issue) *was* the fundamental reason we can’t have “substructs”.

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

Re: [swift-users] Why can't Swift instance methods call class methods without qualification?

[David Sweeris via swift-users]

I'm pretty sure you can have instance and static methods with the same name. 
Requiring `Type.foo()` instead of just `foo()` would tell the compiler which 
one you want.

- Dave Sweeris

> On Jun 30, 2016, at 21:01, Rick Mann via swift-users  
> wrote:
> 
> 
>> On Jun 30, 2016, at 18:47 , zh ao  wrote:
>> 
>> Just a choice made by the language designers to distinguish the call at the 
>> call site. 
>> 
>> You should be aware of using static methods as it may change static 
>> variables, which affects all instances of that class. Normally I think 
>> static methods is designed to use outside the class instance, if you have to 
>> use it inside its instance method. You may need to rethink the pattern you 
>> do.
> 
> I think of static methods as applying to all instances, and so code them to 
> "behave properly" no matter how they're called (since I can't really control 
> who calls it, unless it's my own class). Since it's implicitly obvious (to 
> me) that I mean "this class" when I call one, I find it a bit tedious qualify 
> the call with the class name.
> 
> It's fine, in the end, but I was curious why it was like this, and if there 
> was a more obvious reason why it needed the qualification.
> 
>> 
>> Zhaoxin
>> 
>> On Fri, Jul 1, 2016 at 8:59 AM, Rick Mann via swift-users 
>>  wrote:
>> Why can my instance methods not call class methods without the class 
>> specifier?
>> 
>> class MyClass
>> {
>>   func
>>   foo()
>>   {
>>   classMethod()
>>   }
>> 
>>   class
>>   func
>>   classMethod()
>>   {
>>   }
>> }
>> 
>> Why do I have to call MyClass.classMethod()? Just a choice made by the 
>> language designers to distinguish the call at the call site? I like C++'s 
>> way of treating all static methods as directly available to the instance.
>> 
>> --
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> 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
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] inout params seem to have undefined behavior

[David Sweeris via swift-users]

Oh, ok, I stand corrected. Thanks for the link :-)

Sent from my iPhone

On Jun 11, 2016, at 18:05, Brent Royal-Gordon  wrote:

>> My recollection is that in Swift the subscript operator (`arr[2]` in this 
>> case) can refer to the setter xor the getter, but not both within the same 
>> statement.
> 
> Quite to the contrary. Rather than using the setter directly, Swift often 
> uses `materializeForSet`, a combined get-and-set operation which is much more 
> efficient, particularly when assigning directly into arrays. To keep from 
> having to use very slow access all the time, it imposes a rule (which is not 
> and cannot be enforced by the compiler) that you can't hold two mutable 
> references to overlapping storage simultaneously, or they may do strange 
> things like lose some of the writes you make.
> 
> Here's an old design document discussing some things in this area: 
> 
>  I'm not sure how authoritative it is, but it might give you an idea of 
> what's going on.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] inout params seem to have undefined behavior

[David Sweeris via swift-users]

Ack! “Karl”, not you. For some reason I thought you were the OP until right 
after I clicked send. Sorry for the confusion.

- Dave Sweeris

> On Jun 11, 2016, at 4:06 PM, David Sweeris via swift-users 
> <swift-users@swift.org> wrote:
> 
>> 
>> On Jun 11, 2016, at 3:36 PM, Jens Alfke <j...@mooseyard.com 
>> <mailto:j...@mooseyard.com>> wrote:
>> 
>> 
>>> On Jun 11, 2016, at 11:57 AM, David Sweeris via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>> 
>>> You can’t pass a `let` as an `inout` argument. I’d guess that’s what’s 
>>> happening is the `arr[2]` part is creating a temporary var to which the `&` 
>>> part then provides a reference. 
>> 
>> But `arr` is a var, not a let.
> 
> I know. You’d said that you "can't believe a let variable gets changed”. I 
> was just pointing out that you’re correct, in that the compiler will complain 
> if you try to pass one as an in-out argument.
> 
> 
>>> `b` is then dutifully modified in the function, but there’s no mechanism 
>>> for copying it back into `arr` when `foo` returns
>> 
>> No, it gets copied back using subscript assignment. Remember, `inout` isn’t 
>> really passing the address of the parameter (although the optimizer may 
>> reduce it to that.) It’s literally in-and-out: the caller passes the 
>> original value, the function returns the new value, the caller then stores 
>> the new value where the old value came from.
> 
> I don’t think it can… My recollection is that in Swift the subscript operator 
> (`arr[2]` in this case) can refer to the setter xor the getter, but not both 
> within the same statement. If that’s correct, for there to be a value to pass 
> to the function, `arr[2]` must be referring to the getter version, which 
> means that there’s no setter to update the value when `foo` returns.
> 
> 
>> I am not a Swift guru, but I think the problem in this example is that 
>> there’s a sort of race condition in that last post-return stage: the 
>> function has returned new values for both `arr` and arr[2]`, both of which 
>> get stored back where they came from, but the ordering is significant 
>> because arr[2] will have a different value depending on which of those 
>> assignments happens first.
>> 
>> This smells like those C bugs where the result of an expression depends on 
>> the order in which subexpressions are evaluated — something like “x = i + 
>> (i++)”. The C standard formally declares this as undefined behavior.
>> 
>> The part I’m still confused by is how `acopy` got modified within the `foo` 
>> function, since it’s declared as `let`. After staring at this for a while 
>> longer, I’m forced to conclude that the compiler decided it could optimize 
>> the `b` parameter by actually passing a pointer to the Int and modifying it 
>> directly, and that this has the side effect of modifying the Array object 
>> that `acopy` is pointing to, even though it’s supposed to be immutable.
>> 
>> In other words, this looks like a compiler bug. I can reproduce it with 
>> Swift 2.2 (which is what my `swift` CLI tool says it is, even though I have 
>> Xcode 7.3.1 and I thought that was Swift 2.3?)
> 
> Ah… I see what you mean about a `let` getting modified now… My mistake, I 
> thought you were wondering why `arr` wasn’t `[4, 5, 99]` after foo returned. 
> Yeah, I’m not sure about what’s happening within `foo`... Maybe someone who 
> knows more will come along and provide an explanation, but at the moment I’m 
> inclined to agree — both that you’ve found a bug, and with your guess and to 
> how it’s happening. 
> 
> - Dave Sweeris
> ___
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users 
> <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] Dictionary with optional values

[David Sweeris via swift-users]

I'm not in front of Xcode, so I can't confirm this, but I suspect that 
`optDict["one"] = nil as! Int?` will set "one" to nil, rather than removing 
"one".

Whatever the rules for inferring the type of `nil` when an 
Optional is involved are, it seems like it always 
infers the one I don't want.

Hope that helps.

- Dave Sweeris

> On May 18, 2016, at 05:56, Artyom Goncharov via swift-users 
>  wrote:
> 
> Hi, here is the playground snippet:
> 
> var noOptDict = ["one": 1, "two": 2, "three": 3 ]
> noOptDict["one"] = nil
> noOptDict // “one” is gone
> 
> var optDict: [String: Int?] = ["one": 1, "two": 2, "three": nil]
> optDict["one"] = nil
> optDict // “one” is gone but “three” is still there
> 
> So the first dict instance works as it should, the second using opt values 
> allows to store nil but deletes the key when you assign nil. Is it bug, 
> feature, or both?
> 
> Best wishes,
> Artyom
> ___
> 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] Can't declare variable with same name as func called to assign its initial value

[David Sweeris via swift-users]

I can't recall whether functions and variables can have the same name (though I 
think not), but at the least that error message seems to miss the point.

Sent from my iPhone

> On May 12, 2016, at 14:07, Evan Maloney via swift-users 
>  wrote:
> 
> Adopting the newer Swift style of preferring first parameter labels, I wrote 
> a function:
> 
>func sale(options options: DeepLinkOptions)
>throws
>-> Sale
>{
>// ...implementation...
>}
> 
> I then tried calling it elsewhere, and setting the result to a variable named 
> 'sale', which is coincidentally the same name as the function above:
> 
>let sale = try sale(options: options)
> 
> This line won't compile, failing with the following error and a caret 
> pointing at the second use of 'sale':
> 
>variable used within its own initial value
> 
> In the past, I would've named the function above according to Objective-C 
> conventions, and it might've ended up with a name like 'saleWithOptions'; 
> there'd be no clash. However, with the more terse Swift 3.0 style, we'll 
> probably end up with more situations like mine.
> 
> Is this (should this be?) considered a bug or compiler limitation? Should I 
> file a JIRA? There doesn't seem to be anything for this on bugs.swift.org yet.
> ___
> 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] Stored Property, Externally Read-Only

[David Sweeris via swift-users]

Yep, declare it like this:
public private(set) var lastUpdated: NSDate?

At least I’m pretty sure that’s the syntax. I don’t have Xcode in front of me 
to double-check.

HTH
- Dave Sweeris

> On Apr 29, 2016, at 9:52 AM, Bob Davidson via swift-users 
>  wrote:
> 
> Hello,
> 
> Does Swift have a syntax for allowing a stored property to be internally 
> changed by a class/structure, but external access is read-only?
> 
> For example, my class/structure may have a date property such as 
> “lastUpdated”.  Outside code should have access to read the “lastUpdated” 
> property, but should not be allowed to change it.  Periodically, my class may 
> perform an “update” and would internally change the value of “lastUpdated”.
> 
> The only way I see to support this with a private property and a computed, 
> get-only property:
> 
>   private var internalLastUpdated: NSDate?
>   var lastUpdated: NSDate? { return internalLastUpdated }
> 
> This there a better way?
> 
> Thanks,
> Bob Davidson
> 
> ___
> 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] Nil coalescing operator (??) and function vars

[David Sweeris via swift-users]

Looks like a bug to me.

You can work around it either by substituting the long version:
let fn:(String) -> String = x != nil ? x! : qq
or by declaring qq & fn like this:
let qq:(String -> String)? = { _ in return "..." }
let fn:String -> String = (x ?? qq)!
or like this:
let qq:(String -> String)! = { _ in return "..." }
let fn:String -> String = x ?? qq

Hope that helps.

- Dave Sweeris

> On Apr 18, 2016, at 1:42 PM, Peter Eddy via swift-users 
>  wrote:
> 
> Hello,
> 
> I'd like to understand why I'm unable to use the nil coalescing operator with 
> functions.
> 
> For example, I'd like to write a function that takes an optional function as 
> a parameter and that uses the nil coalescing operator to select a default 
> function if the function's  function parameter is nil, e.g:
> 
> func test(x: ((String) -> String)? = nil) {
> 
>   let qq = { (p:String) -> String in return "..." }
> 
>   let fn: String -> String = x ?? qq
> 
>   fn("test")
> }
> 
> When I do this the compiler complains that:
> 
>   Binary operator '??' cannot be applied to operands of type '((String) -> 
> String)?' and '(String) -> String:
> 
> In the Swift 2.2 Language Guide 
> (https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/BasicOperators.html
>  
> )
>  it states:
> 
> The nil coalescing operator is shorthand for the code below:
> 
> a != nil ? a! : b
> If I use the longhand option then the complier's fine:
> 
> func test(x: ((String) -> String)? = nil)  {
>   
> let qq = { (p:String) -> String in return "..." }
>   
> let fn = x != nil ? x! : qq
> 
> fn("test")
> }
> 
> So why doesn't the nil coalescing operator work for function vars? 
> 
> thanks!
> ___
> 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] Range.count can abort

[David Sweeris via swift-users]

Is there any reason that Distance has to be a simple Int? Since it’s defined 
per-type, UInt64 could use a custom struct without impacting the performance of 
other types:
struct UInt64Distance : Comparable { //I'm not sure what else it needs to 
conform to 
var distance: UInt64
var isPositive: Bool
}
func == (lhs: UInt64Distance, rhs: UInt64Distance) -> Bool {
return lhs.distance == rhs.distance && lhs.isPositive == rhs.isPositive
}
func < (lhs: UInt64Distance, rhs: UInt64Distance) -> Bool {
switch (lhs.isPositive, rhs.isPositive) {
case (false, false): return lhs.distance > rhs.distance
case (false, true ): return true
case (true,  false): return false
case (true,  true ): return lhs.distance < rhs.distance
}
}
... //The rest of `Comparable`

(I’m assuming it’d need `Comparable`, but a quick glance around with cmd-click 
in Xcode didn’t tell me what, if any, protocols `Distance` needs to conform to.)

- Dave Sweeris

> On Apr 15, 2016, at 6:26 PM, Dmitri Gribenko via swift-users 
>  wrote:
> 
> On Fri, Apr 15, 2016 at 4:23 PM, Jens Alfke via swift-users
>  wrote:
>> I’m writing some code that deals with ranges of “sequence numbers”, which
>> are consecutively-assigned positive 64-bit integers, thus Range in
>> Swift. I’m having trouble handling half-open ranges with no maximum, which
>> are very commonly used for representing all items created since a certain
>> time.
>> 
>> The trouble is, if I represent these with Ranges whose endIndex is
>> UInt64.max, those ranges tend to bomb:
>> 
>> let r: Range = 5..> r.count   // FATAL ERROR
>> 
>> 
>> The problem is that Range.count’s type is Element.Distance, and
>> UInt64.Distance is a typealias of … Int. Huh? It’s pretty clear that the
>> distance between two UInt64s can’t be represented by a signed Int64. Why
>> isn’t Distance UInt64?
> 
> Hi Jens,
> 
> The distance is signed so that we can represent negative distances.
> r.distance(from:to:) should be able to measure distances backwards.
> 
> We are aware of this issue, but we don't know of a good solution.
> We'd appreciate your suggestions.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> ___
> 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] Trouble constraining a generic type in an extension

[David Sweeris via swift-users]

Bool isn’t a class (or protocol), so nothing can inherit from it.

Until Swift gains the ability to extend generic types where their parameters 
are *equal* to concrete types, as opposed to where they *inherit from or 
conform to* something, I think the best you can do is this:
public extension check where T: BooleanType {
public func isTrue() { XCTAssertTrue(actual.boolValue) }
}

I *think* the feature you’re trying to use is on the todo list for Swift 3, but 
the last time I said that, I was completely wrong. The swift-evolution mailing 
list probably has more information.

Anyway, I hope that helps.

- Dave Sweeris

> On Apr 12, 2016, at 11:11 AM, Jens Alfke via swift-users 
>  wrote:
> 
> I’ve got a simple generic struct that wraps an instance of its parameter type.
> 
> public struct check {
> let actual: T
> public init(_ a: T) {actual = a}
> ...
> 
> Now I want to add a method that only works with a specific type, Bool:
> public func isTrue(){XCTAssertTrue(actual)}
> 
> As I’d expect, the compiler doesn’t allow this: “Cannot convert value of type 
> ’T’ to expected argument type ‘Bool’”.
> So I’m trying to put this method in an extension that constrains T:
> 
> public extension check {
> public func isTrue(){XCTAssertTrue(actual)}
> }
> 
> This fails with "Constrained extension must be declared on the unspecialized 
> generic type 'check' with constraints specified by a 'where’ clause”. OK, so 
> I add a ‘where’ clause:
> 
> public extension check where T: Bool {
> public func isTrue(){XCTAssertTrue(actual)}
> }
> 
> This produces the error "type 'T' constrained to non-protocol type ‘Bool’”. 
> This confuses me — why is constraining to a non-protocol type an error? The 
> Swift Programming Language says “the ‘where’ clause … can express the 
> constraints that a generic type T inherits from a class C”.
> 
> —Jens
> ___
> 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] Generators vs. errors

[David Sweeris via swift-users]

I think I’d either just end the sequence on an error, or do like you were 
thinking and have a function/computed property that gives an array containing 
all the rows which had an error or something.

I’m not a DB guy, though.

- Dave Sweeris

> On Apr 12, 2016, at 1:53 PM, Jens Alfke via swift-users 
>  wrote:
> 
> What should one do, when implementing a Generator, if the underlying data 
> source can experience errors? Generator.next isn’t allowed to throw, only to 
> return nil at the end of the sequence.
> 
> The only idea I can think of is to add an `error` property to my Generator 
> implementation, and request that the caller check it after the iteration 
> ends, and/or a `checkForError()` method that can throw an error if there is 
> one:
>   var q: Query = db.query(…)
>   for (row in q) { … }
>   q.checkForError()
> 
> As the example implies, this problem comes up when creating Swift bindings 
> for database iterators/cursors. Generator is the obvious protocol to 
> implement, especially since without it you don’t get the idiomatic for/in 
> loop, but the `next` method does have to hit the database, so it has the 
> possibility of I/O errors.
> 
> Another possibility is to do all the failable database work up front in the 
> `query` method that creates the Generator, but this means all the results 
> have to be cached in memory, which isn’t scaleable. (Keep in mind I work for 
> a database company  whose customers often have 
> multi-terabyte data sets.)
> 
> I know there’s been a proposal (by Brent Royal-Gordon) to allow property 
> accessors and subscripts to throw, which I strongly endorse, but I think we 
> also need to allow Generators to throw. Fodder for the swift-evolution list…
> 
> —Jens
> ___
> 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