|
pokeyman posted:This doesn't really have much to do with Swift, though. We can take it to the Apple dev thread. On this note, my presumption is that sooner or later (probably when Xcode 6 is formally released), the Swift thread is going to be merged into the Apple dev thread, since a large portion of it is API calls, which are (effectively) the same between languages. Also, playgrounds are a fantastic way to show off the language to my co-workers, because I can just type some quick code and it shows it live updating. It's kind of nice to feel script-like, instead of having a heavyweight application around to do stuff in. I'm compiling my list of Radars to file. When I get a chance this weekend, I'll pull code together for them and do a dump. Sorry it's taking me so long.
|
# ? Jun 10, 2014 04:30 |
|
|
# ? May 15, 2024 03:37 |
|
We'll see! If I feel like the thread has outlived its usefulness in a few months, I'll definitely just close it.
|
# ? Jun 10, 2014 04:43 |
|
rjmccall posted:It makes the associated type functionally dependent on the principal type. With Sequence<T>, it is theoretically sensible for a type to conform to both Sequence<Int> and Sequence<Float>. That's rarely useful, and it makes the type system far more complicated. I'm starting to wish I had protocol<T> (or at least could specify that an associated type is a generic type) because jumping through the hoops necessary to make protocols compose with just associated types is a bit maddening. That might be my failure to understand and/or apply them properly though. This doesn't work (obviously): code:
code:
Simulated fucked around with this message at 05:28 on Jun 10, 2014 |
# ? Jun 10, 2014 04:59 |
|
I have spent an amusing amount of time talking about making a monad protocol recently. I don't understand how your C# example works. It looks to me like it both (1) shouldn't type-check because you're not applying the same number of arguments consistently to your protocol and (2) erases the concrete monad type across bind. Monad is an example of a higher-kinded protocol: the thing that conforms to the protocol is not a type, it's a type function (generally, an unapplied generic type). That's feasible to add as a feature, but seeing as, frankly, the only use I've ever seen for that even in Haskell is Monad, it is not something we are going to fall over ourselves rushing into the language.
|
# ? Jun 10, 2014 05:12 |
|
rjmccall posted:I have spent an amusing amount of time talking about making a monad protocol recently. Sorry, I messed it up. That's what I get for not firing up my VM first. I fixed my previous post. Anyway Bind in C# is actually an extension method (SelectMany) so I think I see where I need to go now and it makes far more sense. I got distracted trying to model it with a protocol when it doesn't belong there to begin with.
|
# ? Jun 10, 2014 05:33 |
|
Oh, another question rjmccall: Is there an underlying type I can use to represent a closure or is typealias the only way to get out of a labyrinth of parens? For that matter, do you know if/when we will see documentation of the Swift standard library? I'm using unofficial sources out on the net right now. There are a lot more types and protocols than are listed in the official reference. Third question: What happens when I need a huge Dictionary? Isn't that going to run out of stack space? Would the current suggestion be to create an NSDictionary if we want one on the heap?
|
# ? Jun 10, 2014 14:58 |
|
Ender.uNF posted:Is there an underlying type I can use to represent a closure or is typealias the only way to get out of a labyrinth of parens? You mean, if you need to write a higher-order function type, and it's not just curried so you can't take advantage of the right-associativity of ->, is there a way to write the function type as something like Function<Int, Void> instead of having to parenthesize (Int -> Void)? Not right now, sorry. Ender.uNF posted:For that matter, do you know if/when we will see documentation of the Swift standard library? I'm using unofficial sources out on the net right now. There are a lot more types and protocols than are listed in the official reference. I think it's being worked on. Note that anything starting with an underscore is logically private and will be actually private when we implement access control. Ender.uNF posted:Third question: What happens when I need a huge Dictionary? Isn't that going to run out of stack space? Would the current suggestion be to create an NSDictionary if we want one on the heap? Dictionaries don't actually store data on the stack. It's like a C++ type: the Dictionary value itself is just a small, fixed-size "header" which owns a reference to data stored on the heap, and the type maintains the abstraction that different Dictionary values have independent collections of values and keys.
|
# ? Jun 10, 2014 17:20 |
|
Common themes in #swift-lang: How do I get the length of a string? Why isn't Swift perfect? Four years is far longer than Apple should need to create a programming language. Why does Swift make it so hard to just use AnyObject everywhere? Swift is just like Objective C + X, where X is a language that has very little in common with Swift. I want to learn Swift but I don't own any Apple products.
|
# ? Jun 10, 2014 18:54 |
|
More adventures in Core Data interop: If I pass a string to an ObjC method from Swift, and use that string as the name of a Core Data entity, it looks up the NSEntityDescription fine on the simulator, but fails on the device. That is, the following code: code:
(ObjC) code:
On the simulator, this returns an NSEntityDescription for the name. On the device, this returns nil. I worked around it by passing the string from inside an ObjC method, but it's still some twilight zone stuff. Edit: in the debugger, I looked: it is filling *name with something that looks to my eyes like "Entity", it even compares with an NSString constructed by the debugger properly... But it doesn't match the key in the entitiesByName dictionary in my object model. Dessert Rose fucked around with this message at 19:45 on Jun 10, 2014 |
# ? Jun 10, 2014 19:40 |
|
Thank you for overflow checking. Punks will bitch about the performance impact, but they are wrong and you are right and you should feel good. It's too bad that Rust wasn't appropriate for you to get involved with 3 years ago; it would definitely have helped converge it usefully, but I understand the low probability of Apple telegraphing a major platform shift that far ahead. Surprised that the playground stuff doesn't do whole-program parsing and then execution. Seems like you end up losing a lot of utility of copying working code into a playground can make it be not-working code. Is it for performance reasons or just wanting to make later-on syntax errors less disruptive?
|
# ? Jun 10, 2014 20:40 |
|
rjmccall posted:I have spent an amusing amount of time talking about making a monad protocol recently. Monad, functor,applicative are foundational for the neat abstractions you get. Having parser combinators is pretty great. And then you can do stuff like ghc.generics, free monads, uniplate and all the stuff that makes life easier when dealing with regular old polymorphism. F# is stuck because the clr can't deal with it iirc It would make a lot of sense, especially if you already elaborate into a language that supports it. Mostly for library authors.
|
# ? Jun 11, 2014 00:09 |
|
rjmccall posted:You mean, if you need to write a higher-order function type, and it's not just curried so you can't take advantage of the right-associativity of ->, is there a way to write the function type as something like Function<Int, Void> instead of having to parenthesize (Int -> Void)? Not right now, sorry. You know at first I thought "WTF is he talking about?" Then I opened the book in iBooks and did a search for "curry" and there it is on page 768: Curried functions and methods. This makes me very happy. quote:Dictionaries don't actually store data on the stack. It's like a C++ type: the Dictionary value itself is just a small, fixed-size "header" which owns a reference to data stored on the heap, and the type maintains the abstraction that different Dictionary values have independent collections of values and keys. I'm sure this is just my confusion but this section from the guide seemed to imply that if the keys or values are structs they will be stack allocated, but that was my incorrect assumption. quote:Whenever you assign a Dictionary instance to a constant or variable, or pass a Dictionary instance as an argument to a function or method call, the dictionary is copied at the point that the assignment or call takes place. This process is described in Structures and Enumerations Are Value Types. So just to clarify how Dictionary<K,V> actually works: 1. Dictionaries declared let are constant in both size, keys, and values if the values are value types. If the values are references then the underlying object can still be modified. (If you use mutating keys then you deserve what you get.) 2. Dictionaries declared var are mutable. 3. In either case, the keys and values are heap allocated. 4. Passing a dictionary does copy the dictionary, but it's just copying a small header struct 5. When the guide talks about copying the whole dictionary, it just means logically the program behaves as if everyone has their own copy of the dictionary, even though in reality they may share the data until someone attempts a mutation; iow the headers all point to the same hash buckets until someone ruins the party And Array<T> works the same way, except you can mutate a supposedly constant array if you don't change its size (which still seems crazy to me). Is this all correct? Further question: Assume that I want to pass a dictionary around, mutating it along the way. I should wrap that in my own class to avoid the repeated copying behavior, yes? Or possibly vend mutation functions that operate on my closed over dictionary. Or would that be attempting to defeat compiler optimizations? edit: Anyone have success creating a framework and using unit tests written in Swift? I haven't done anything special whatsoever and my first attempt to run a test fails: quote:Undefined symbols for architecture x86_64: Doesn't seem to make any sense, both the framework and the test project are set to compile for x86_64. Simulated fucked around with this message at 04:41 on Jun 11, 2014 |
# ? Jun 11, 2014 03:37 |
|
Ender.uNF posted:You know at first I thought "WTF is he talking about?" Hooray. I put that in at a whim a few years ago, and a small cabal of us have been valiantly defending it from getting idly ripped out ever since. It helps that we internally model methods as being curried over self, so some amount of the code would be justified regardless. Ender.uNF posted:I'm sure this is just my confusion but this section from the guide seemed to imply that if the keys or values are structs they will be stack allocated, but that was my incorrect assumption. Like C, all types in Swift have a (direct) storage size and alignment, which is how much (direct) space a value of that type takes up in the entity which contains it. (For this purpose, you can think of a stack frame as being a weird struct that has all of its local variables as fields.) For a class, of course, that's just the size and alignment of a pointer. For a struct or enum, that size and alignment is large enough to include all the stored properties of the type, which is to say, all of the stored properties are stored inline within the struct, which is itself stored inline within its container. Basically, where a value type is stored is dependent on what's holding on to the value. Ender.uNF posted:So just to clarify how Dictionary<K,V> actually works: Yes, with the proviso that of course you can also declare your own struct type that contains a class reference and makes no effort to feel like a real value type. Ender.uNF posted:2. Dictionaries declared var are mutable. Right. Ender.uNF posted:And Array<T> works the same way, except you can mutate a supposedly constant array if you don't change its size (which still seems crazy to me). We got a lot of great feedback about this; it's under serious discussion. Ender.uNF posted:Further question: Assume that I want to pass a dictionary around, mutating it along the way. I should wrap that in my own class to avoid the repeated copying behavior, yes? Or possibly vend mutation functions that operate on my closed over dictionary. Or would that be attempting to defeat compiler optimizations? If you're just passing it around temporarily, you can use pass-by-reference to avoid unnecessary copies without going so far as to put it on the heap. Otherwise, yes, a class is a reasonable way of sharing a mutable dictionary, and it also gives you an obvious way to start introducing real abstraction around it.
|
# ? Jun 11, 2014 06:07 |
|
FYI: you cannot extend a built-in generic type from within a framework with anything that touches the type parameters; the linker will not find the same mangled names and will complain that the symbols are not found. Simplest test case: 1. Create a framework 2. Add swift file with this code: code:
code:
pre:Undefined symbols for architecture x86_64: "__TFVSs10Dictionary5NotOKUSs8Hashable___fGS_Q_Q0__FQT_", referenced from: __TFC23QuickTestFrameworkTests23QuickTestFrameworkTests11testExamplefS0_FT_T_ in QuickTestFrameworkTests.o ld: symbol(s) not found for architecture x86_64 I ran into this while trying to setup a framework and github project for my little non-standard library. I have basic SequenceOf<T> join operations working (left hash join), moving on to group by. I'm not tackling composite keys just yet, just trying to prove the concept. Hopefully this bug is resolved and I can get it out there for comments/contributions.
|
# ? Jun 11, 2014 06:44 |
|
I've been reading the book and watching the talks and I'm really into it, it seems like a really well designed language. But I was wondering, why have all those global generic functions like enumerate and the like rather than have them attached to the appropriate types as instance methods and computed properties?
|
# ? Jun 11, 2014 16:19 |
|
chaosbreather posted:I've been reading the book and watching the talks and I'm really into it, it seems like a really well designed language. But I was wondering, why have all those global generic functions like enumerate and the like rather than have them attached to the appropriate types as instance methods and computed properties? So you don't have to rewrite them over and over, or force everything to inherit from some base class.
|
# ? Jun 11, 2014 17:34 |
|
Are there any options for those who aren't paid developers that want to start tinkering with Swift, other than waiting a couple months for Xcode 6? Even if just to compile examples from the Swift book and run them in a terminal or something.
|
# ? Jun 11, 2014 18:19 |
|
geera posted:Are there any options for those who aren't paid developers that want to start tinkering with Swift, other than waiting a couple months for Xcode 6? Even if just to compile examples from the Swift book and run them in a terminal or something. Covered earlier in the thread - not currently. There are hints that people in Apple want to open-source Swift, but either the decision hasn't been made yet or they are still working on cleaning up the repo for public release. Personally, my expectation is that it will be open source at some point.
|
# ? Jun 11, 2014 18:41 |
|
Ender.uNF posted:Covered earlier in the thread - not currently. There are hints that people in Apple want to open-source Swift, but either the decision hasn't been made yet or they are still working on cleaning up the repo for public release.
|
# ? Jun 11, 2014 18:59 |
|
Yeah, it'd be nice if they opened up the XCode download to free developers.
|
# ? Jun 11, 2014 19:39 |
|
smackfu posted:Yeah, it'd be nice if they opened up the XCode download to free developers. Do you mean Xcode in general? Because that is available in the Mac App Store right now. Just not the beta version.
|
# ? Jun 11, 2014 20:13 |
|
The required type casting is feeling brutal. For a function that takes a CGFloat:code:
code:
|
# ? Jun 11, 2014 20:18 |
|
can you perhaps writecode:
|
# ? Jun 11, 2014 20:46 |
|
That worked, thanks.Gul Banana posted:not tested, i'm at a PC. i'm also not sure if there's a way to limit the scope of extensions.. ideally this would be something you import for a specific source file or module. Can you explain why it would be bad to have this project wide? If it's a valid conversion, what's the harm?
|
# ? Jun 11, 2014 21:13 |
|
lord funk posted:The required type casting is feeling brutal. For a function that takes a CGFloat: Assuming that offset isn't a CGFloat for some reason: code:
|
# ? Jun 11, 2014 22:29 |
|
Gul Banana posted:can you perhaps write Where did you find @conversion? edit: My first /usr/bin/swift eternal loop! Still churning away as I type this. Rebooting the VM to see if it goes away. edit2: Paste this code in and try to compile: code:
Simulated fucked around with this message at 00:01 on Jun 12, 2014 |
# ? Jun 11, 2014 22:40 |
|
Any idea why this is an issue?code:
|
# ? Jun 12, 2014 01:34 |
|
Ender.uNF posted:edit: Anyone have success creating a framework and using unit tests written in Swift? I haven't done anything special whatsoever and my first attempt to run a test fails: The issue with this is that the Swift standard library isn't copied into the framework or the test bundle like it is for apps. You may be able to manually copy them into your test bundle so they're available when tests are run.
|
# ? Jun 12, 2014 02:06 |
|
ultramiraculous posted:Any idea why this is an issue? There are some soundness restrictions about what you can do involving associated types (including Self) when you just have a protocol value. In this case, we could heroically let you iterate through and bind the elements to Any or something, so feel free to file a bug.
|
# ? Jun 12, 2014 02:29 |
|
Ender.uNF posted:edit: Anyone have success creating a framework and using unit tests written in Swift? I haven't done anything special whatsoever and my first attempt to run a test fails: I've been able to get unit tests written in Swift (aside from the lack of mocking), so it's just stuff with the framework. In my opinion, though, the testing stuff for Swift isn't quite there yet--which makes sense with how much work is elsewhere in the language! On my list of radars to file this weekend is some stuff related to testing, so it'd probably be good to make your voice known there as well.
|
# ? Jun 12, 2014 02:57 |
|
eschaton posted:The issue with this is that the Swift standard library isn't copied into the framework or the test bundle like it is for apps. You may be able to manually copy them into your test bundle so they're available when tests are run. The issue isn't running, it's that the tests can't even build due to the linker failure. There is a build setting EMBEDDED_CONTENT_CONTAINS_SWIFT that seems to indicate that the standard swift libraries will be included in the product when enabled, but it doesn't make any difference. Copying Swift.swiftmodule to the build objects x86_64 directory doesn't help. Neither does import Swift. Any ideas on how to go about this? I suspect I would have the same problem trying to use the framework from another app but I will test that later tonight. edit: Unrelated note, I have working filter, join, and group by now. Tuples work excellently for projecting values, though I don't know that they can be used as keys since I presume they aren't hashable. Would be nice if they were though (assuming all of the items in the tuple are hashable). Simulated fucked around with this message at 03:27 on Jun 12, 2014 |
# ? Jun 12, 2014 03:02 |
|
rjmccall posted:There are some soundness restrictions about what you can do involving associated types (including Self) when you just have a protocol value. Is there a reason that Array and Dictionary and whatnot implement only the vanilla Sequence instead of something like SequenceOf<T> (if it wasn't a structl)? Same for Generators (IndexingGenerator, etc) and GeneratorOf<T>. It mostly just seems like all the collections share common roots like Sequence, but they ditch some type information along the way.
|
# ? Jun 12, 2014 04:20 |
|
ultramiraculous posted:Is there a reason that Array and Dictionary and whatnot implement only the vanilla Sequence instead of something like SequenceOf<T> (if it wasn't a structl)? Same for Generators (IndexingGenerator, etc) and GeneratorOf<T>. It mostly just seems like all the collections share common roots like Sequence, but they ditch some type information along the way. They don't lose information, they just keep it in associated types, which admittedly makes it awkward (impossible?) to talk about Sequences of specific types as types rather than as generic constraints.
|
# ? Jun 12, 2014 04:59 |
|
Ender.uNF posted:Where did you find @conversion? dumped the LLVM IR which implements the few builtin conversions. lord funk posted:Can you explain why it would be bad to have this project wide? If it's a valid conversion, what's the harm? implicit conversion is a powerful feature, but it introduces unpredictability: by including a file in your project, you can change the meaning of another file, reducing the type-safety it previously had. if it becomes a documented feature of swift, i'll probably do something like put the implicits in a separate project and import that only in source files which i want to use them, making it opt-in. the other thing i was going to mention is that this particular conversion will behave differently on 32- and 64-bit systems, but rjmccall already demonstrated an implicit-free way around that: rjmccall posted:
|
# ? Jun 12, 2014 06:08 |
|
rjmccall posted:They don't lose information, they just keep it in associated types, which admittedly makes it awkward (impossible?) to talk about Sequences of specific types as types rather than as generic constraints. is there a moral equivalent, in Swift, of this C# code? code:
|
# ? Jun 12, 2014 06:19 |
|
Gul Banana posted:is there a moral equivalent, in Swift, of this C# code? As long as you're just calling the function, there's absolutely no reason for it to not be generic, i.e.: Swift code:
|
# ? Jun 12, 2014 09:18 |
|
ah, i hadn't realised you could express a constraint on a type's associated type like that. covers some major use cases at least
|
# ? Jun 12, 2014 10:30 |
|
Just noticed that book 2, Using Swift with Cocoa and Objective-C, is up on iBooks: https://itunes.apple.com/us/book/using-swift-cocoa-objective/id888894773?mt=11
|
# ? Jun 13, 2014 15:08 |
|
rjmccall, thanks for the thread and your responsiveness. Looking at an example from the book of unwrapping an optional combined with a switch statement, it seems to me like a case that could easily be simplified: code:
code:
|
# ? Jun 14, 2014 09:46 |
|
|
# ? May 15, 2024 03:37 |
|
Really, really new to programming (some HTML, JavaScript, CSS, but no real languages) guy here, jumping headfirst into Swift. Surely this is a stupid question, but I'm running the below code from Chapter 1 of the book in a playground (which is a neat thing!) -- why does largeKind need to be optional to not have the console throw errors? Edit - DERP, because if it's not optional I need to define it when I name it. Leaving this here in case some idiot has the same question. code:
Moogs fucked around with this message at 21:02 on Jun 14, 2014 |
# ? Jun 14, 2014 20:39 |