|
There's a huge amount of bad taste and cargo-culting in the functional community. It's a "well, we're functional programmers so we're obviously a cut above the rest, now here's an unnecessary monstrosity of syntax that's worse than anything in perl" sort of thing. There is a reason that "advanced" Haskell and Scala look the way they do, and it is not because that is somehow core to the mathematical purity of the model. Always remember that as a programmer your goal is to write good code that solves problems, not to make your job more interesting by finding clever ways to eliminate keystrokes. It's something we're all susceptible to, but it's a bad instinct.
|
#
?
Feb 16, 2015 08:47
|
|
|
|
| # ? May 14, 2024 16:27 |
|
|
rjmccall posted:There's a huge amount of bad taste and cargo-culting in the functional community. It's a "well, we're functional programmers so we're obviously a cut above the rest, now here's an unnecessary monstrosity of syntax that's worse than anything in perl" sort of thing. There is a reason that "advanced" Haskell and Scala look the way they do, and it is not because that is somehow core to the mathematical purity of the model. What you mean scalaz's ★ operator doesn't mean "monad transformer" or whatever to most people?
|
|
#
?
Feb 16, 2015 09:19
|
|
|
ultramiraculous posted:What you mean scalaz's ★ operator doesn't mean "monad transformer" or whatever to most people? What about the ☆ one? e: seriously having a star as an operator is dumb enough, but then having a filled one and a hollow one as operators is even loving worse. IIRC they're related too?
|
|
#
?
Feb 16, 2015 09:38
|
|
|
Look Around You posted:What about the ☆ one? The empty star operator means you haven't favorited the left side of the expression yet.
|
|
#
?
Feb 16, 2015 14:49
|
|
|
How do you even type that?
|
|
#
?
Feb 16, 2015 19:47
|
|
|
⌃⌘Space and then you select it with the mouse.
|
|
#
?
Feb 16, 2015 19:59
|
|
|
Look Around You posted:What about the ☆ one? Yeah they were both related to the same operation with modads. Phone posting, but I have a horrible feeling that they represented opposite prefix/postfix operator affinity (or at least there was another horrible operator that was like that). Just because you can, doesn't mean you should. ultramiraculous fucked around with this message at 07:09 on Feb 17, 2015 |
|
#
?
Feb 16, 2015 22:21
|
|
|
They implemented monads with the stupid operators because they thought it was too easy to tell what was going on.
|
|
#
?
Feb 16, 2015 23:04
|
|
|
fleshweasel posted:They implemented monads with the stupid operators because they thought it was too easy to tell what was going on. They should've added a native concept of combining diacritics to the language to represent the functional concept of composition. e: good luck distinguishing ± from + combined with an underbar diacritic!
|
|
#
?
Feb 17, 2015 06:36
|
|
|
code: Operator overloading with overloaded definitions appears to be strangely sensitive to the order of definition. Swap the two functions around and it will fail to compile. Strangely, resolution still picks the correct definition in the working case (a chain of optionals should infer an optional result type, while a chain terminating in a non-optional should infer a non-optional result type). Found this when verifying bugs against 1.2; this was filed as rdar://17842481 during the original beta.On another note, is there a story forthcoming for handling visibility for unit testing? Now that we can't make extensions visible for types defined in other modules, it further complicates the unit testing story. The whole rationale for how public/private work is completely smashed because I have to consider public visibility for everything I do, otherwise none of it is visible to the unit test project.
|
|
#
?
Feb 22, 2015 22:01
|
|
|
That sounds like a bug. (Also, that's just an example, right? Because ?? already does that; it didn't always, so I wanted to make sure you knew.) I agree that ideally you shouldn't have to spuriously mark stuff public just to get unit tests to work. I know we've talked about it, but I don't know what the current state of the fix is. Are your unit tests really in a completely different project, not just a different target?
|
|
#
?
Feb 23, 2015 03:49
|
|
|
rjmccall posted:That sounds like a bug. (Also, that's just an example, right? Because ?? already does that; it didn't always, so I wanted to make sure you knew.) Yeah, I just had that handy from the original beta bug report (before ?? worked like it does now). Maybe I'm missing something but for frameworks and mixed ObjC/Swift projects the unit tests pull in the project code as a module so anything not public isn't visible.
|
|
#
?
Feb 23, 2015 17:33
|
|
|
Ender.uNF posted:Maybe I'm missing something but for frameworks and mixed ObjC/Swift projects the unit tests pull in the project code as a module so anything not public isn't visible. Yeah, that's what we still need to fix. But when we fix it, I wouldn't be surprised if the tests need to be in the same project. Maybe I shouldn't speculate; I haven't been following that discussion very closely.
|
|
#
?
Feb 23, 2015 18:42
|
|
|
Anyone have a cleaner method for initializing values related to a property where you need to respond in both didSet and init? Either I end up just saying gently caress it and making the related fields implicitly unwrapped optional (which feels gross) or I have to do this stupid dance:code: (can't call functions on self until after super init )I understand why initialization works this way but I do wonder if we could have a way to trigger willSet/didSet prior to calling super? Perhaps if they were declared with explicit optional parameters or something? code:
|
|
#
?
Feb 24, 2015 07:18
|
|
|
It's an interesting idea. We could have an attribute that makes initialization call didSet and then impose initializer-like restrictions on didSet, i.e. disallowing the oldValue parameter and only allowing general use of the current property. A more convenient alternative to extracting that logic into a global or static helper function and calling it in two places. Worth a radar. In the meantime, you should be able to put your helper logic in a global function and call it at the right time.
|
|
#
?
Feb 24, 2015 18:55
|
|
|
Is there an equivalent to Objective-C's "class" data type in swift? I'm having trouble finding anything that mirrors the type used in this function declaration:code:e: or if any of you wizards know a better way to accomplish something along the lines of what they're doing in that post (in swift, with Parse.com in my case), please chime in. This is exhausting to figure out 
MrSaturn fucked around with this message at 23:42 on Feb 24, 2015 |
|
#
?
Feb 24, 2015 23:40
|
|
|
Replying to myself. Based on documentation, I think I'm just looking for AnyClass, which seems strange. https://developer.apple.com/library...object_getClass
|
|
#
?
Feb 24, 2015 23:58
|
|
|
rjmccall posted:It's an interesting idea. We could have an attribute that makes initialization call didSet and then impose initializer-like restrictions on didSet, i.e. disallowing the oldValue parameter and only allowing general use of the current property. A more convenient alternative to extracting that logic into a global or static helper function and calling it in two places. Worth a radar. Filed, radar://19948325 . Please excuse the spelling errors, I'm on muni to NSCoder night and this iPad has developed some "interesting" autocorrect habits.
|
|
#
?
Feb 25, 2015 04:01
|
|
|
Posting on the off chance there's anyone from Dublin reading -- there's a Swift meet today and the next couple of Wednesdays in Citi Bank on the quays. https://twitter.com/SwiftlyDublin The Eventbrite page doesn't seem to be working this week so just show up for 7pm and ask for Aman. And the Xcake group covered Swift a bit earlier in the month and undoubtedly will again.
|
|
#
?
Feb 25, 2015 16:31
|
|
|
rjmccall posted:stuff Found three new issues in the beta. I'd file radars but bugreport.apple.com just redirects me back to the login page. 1. If a function taking a closure contains only a call to another function taking a closure that has an error (e.g. UInt changed to Int in the closure signature), Swift will mis-attribute the error to the outer closure. If you stick a let statement or something in there then it correctly identifies the inner call as being passed an incorrect closure. 2. The Xcode Fix-it thing has a lag time for updating; if you apply a fix-it (e.g. converting "as" to "as!"), the following fixits will be off by... you guessed it! one character! They're obviously using cached text positions that don't adjust for the inserted character, so it helpfully offers to replace " a" with " a!". 3. The Swift syntax upgrade tool does not upgrade the unit tests P.S. The Xcode release notes link on the official Swift blog give an unauthorized access page because it links to the old version of the release notes. Simulated fucked around with this message at 18:48 on Feb 26, 2015 |
|
#
?
Feb 26, 2015 18:28
|
|
|
Sheesh, talk about software quality at Crapple. They should've implemented Swift in a memory-safe language like Rust, or PHP.
|
|
#
?
Feb 26, 2015 21:09
|
|
|
sarehu posted:Sheesh, talk about software quality at Crapple. They should've implemented Swift in a memory-safe language like Swift.
|
|
#
?
Feb 26, 2015 21:16
|
|
|
Shortly after Swift was first announced I had a very dumb argument with a person who was convinced that the Swift compiler would be both faster and more reliable if they'd written just enough of it in C++ to bootstrap and then wrote the real thing in Swift.
|
|
#
?
Feb 26, 2015 21:35
|
|
|
Rewrite the whole thing in WebObjects.
|
|
#
?
Feb 26, 2015 22:34
|
|
|
Self-hosting is righteous. Or are you saying that if I want more reliable code I should choose C++ over Swift?
|
|
#
?
Feb 26, 2015 22:53
|
|
|
As I understand it, the sorts of things a language needs to be able to do in order to self-host don't have much in common with the sorts of things a language needs to do in order to be generally usable in developing GUI-having applications. It therefore becomes a matter of time and priorities: do you spend the time to self-host because...reasons; or do you spend the time building a language that people can use to create apps? For content: How is Swift/Obj-C interoperability for reals? I have someone on my team that wants to be aggressive about writing new stuff in Swift and converting over, but I'm not sold that it's going to be smooth sailing. Was wondering what sorts of real-life experience people have had.
|
|
#
?
Feb 27, 2015 05:59
|
|
|
It can be bumpy. Certain things can't show up in the signatures of functions you want to expose to objective C, like tuples. You need to configure your project settings correctly if you're including a swift dylib in an objective C app project. It was painful sometimes, especially when I just couldn't tell what I was doing wrong, but in the end the expressiveness of swift made it worth it to me. And unless you have the money for a ground up rewrite, transitions have to be gradual. I don't have experience with how swift 1.2 improves this. I would love to hear from you folks who do.
|
|
#
?
Feb 27, 2015 06:35
|
|
|
Axiem posted:As I understand it, the sorts of things a language needs to be able to do in order to self-host don't have much in common with the sorts of things a language needs to do in order to be generally usable in developing GUI-having applications. It therefore becomes a matter of time and priorities: do you spend the time to self-host because...reasons; or do you spend the time building a language that people can use to create apps? Another argument is that it can kindof misleading. The needs and priorities of someone writing a compiler can be pretty different from the needs of other programmers. I like ADTs and pattern-matching, and we have a vision for where we're going with them in Swift, and I'm not saying that they're useless for other programmers... but if we were self-hosting they'd be far more complete, by necessity, and that focus means that there would be other features that would have gotten less attention, and there would always be a tension between optimizing for our own convenience and considering the needs of the users who actually matter. There are already enough languages that excel at writing a compiler.
|
|
#
?
Feb 27, 2015 07:20
|
|
|
Development time would also be longer because you wouldn't have all the tools available outside the language, like rock solid editor, debugger support.
|
|
#
?
Feb 27, 2015 09:04
|
|
|
rjmccall: I had no reason to expect this to work, but taking the address of an instance property that has didSet/willSet still manages to fire the willSet/didSet on the Swift side. I don't know what trampoline magic makes that work but I like it.
|
|
#
?
Feb 28, 2015 00:09
|
|
|
Is there any way to specify @autoclosure for an enum payload in Swift 1.2? I assumed that the following would work, but it's treated as a syntax error:code:code:Ender.uNF posted:I'd file radars but bugreport.apple.com just redirects me back to the login page. I had the same thing yesterday. Purging cookies for apple.com fixed it.
|
|
#
?
Feb 28, 2015 04:55
|
|
|
Dr. McCheese posted:Is there any way to specify @autoclosure for an enum payload in Swift 1.2? No. Someone was working on locking down on the number of places we accepted it — it's only supposed to be allowed in parameters, but we weren't representing it in the right way to get that behavior — and broke this pattern. We realized what we'd done, thought about it, and decided we didn't care; sorry. Just make a standalone constructor function that takes the values you want (by value!) and embeds them in some way into your enum; that's better practice anyway, since you'll actually capture the values instead of capturing the expression that computes them. While you're at it, a class is a better way to embed the values than a function. We'll have recursive enums eventually, I promise.
|
|
#
?
Feb 28, 2015 23:50
|
|
|
Ender.uNF posted:rjmccall: That's a general thing with Swift inout parameters: you can pass a reference to a computed property inout, and it's implemented by reading the property into a temporary, passing the address of that, and writing the value back after the call. The assumption, codified in the language rules, is that the callee won't try to keep the reference alive longer than the call, e.g. by capturing the inout parameter in a closure. Swift is still memory-safe, so the compiler isn't supposed to generate code that crashes if you violate that; but it's against the rules, and the compiler is allowed to do things that lead to unexpected behavior, like writes to the captured inout parameter "disappearing". If the property is stored, we should be passing the actual memory backing it; doing that safely even for class properties (which can be made computed in an override) has been fun. The C interop bit here is that we allow you to pass variables inout as a C pointer argument. Of course, the C function can do things that break memory-safety with this feature, but it's C, of course it can do that.
|
|
#
?
Mar 1, 2015 00:12
|
|
|
rjmccall posted:While you're at it, a class is a better way to embed the values than a function. Oh, of course, pointers occupy a fixed amount of space, so either wrapping values in Box<T> or using enum Foo<TA: AnyObject, TB: AnyObject> will work. Thanks for running this thread and for providing your insights.
|
|
#
?
Mar 2, 2015 10:27
|
|
|
Dr. McCheese posted:Oh, of course, pointers occupy a fixed amount of space, so either wrapping values in Box<T> or using enum Foo<TA: AnyObject, TB: AnyObject> will work. Right. In Swift, class references are one pointer and functions are two; this might make the direct storage size of your enum slightly smaller, depending on the other cases. In both cases, a heap allocation is required. The other advantage is that class storage is transparent. Absent heroic optimization, with a function the compiler always has to call something to get the value; with a class, the compiler can pull the storage directly out of memory, which both is faster and has a lot of nice second-order effects. (To this end, you should also make your class private or final. This shouldn't really be required — the compiler should be able to figure this out reliably even in debug builds — but for now it is.)
|
|
#
?
Mar 2, 2015 19:49
|
|
|
Hey rjmccall, How do I println the size of an object in memory? I want to print the size of my NSCache but it yells at me when I try to do a malloc_size(UnsafePointer<NSCache>(self.cache)).
|
|
#
?
Mar 5, 2015 00:39
|
|
|
Doh004 posted:How do I println the size of an object in memory? I want to print the size of my NSCache but it yells at me when I try to do a malloc_size(UnsafePointer<NSCache>(self.cache)). The direct answer is that you can make an Unmanaged reference and then get that as an opaque pointer. The actual answer is that malloc_size doesn't do what you're hoping. It'll at best print the instance size of an NSCache object, i.e. the amount of storage needed for the ivars of NSCache and its superclasses, not the number of entries in the cache or its current capacity, and certainly not the amount of memory currently being kept alive by a reference from the cache.
|
|
#
?
Mar 5, 2015 07:30
|
|
|
rjmccall posted:The direct answer is that you can make an Unmanaged reference and then get that as an opaque pointer. Hmm, okay. Would instruments be the true way to get the actual size of those objects than?
|
|
#
?
Mar 5, 2015 15:46
|
|
|
Instruments might help. It doesn't look like NSCache has much in the way of API for it; I think you're just supposed to trust that it's doing the right thing.
|
|
#
?
Mar 5, 2015 18:24
|
|
|
|
| # ? May 14, 2024 16:27 |
|
|
rjmccall posted:Instruments might help. It doesn't look like NSCache has much in the way of API for it; I think you're just supposed to trust that it's doing the right thing. Yeah, that's what I'm worried about! But thank you for the help! I've been learning quite a bit as I reinvent the wheel and create my very own super performant (read: non-crashing) image cache.
|
|
#
?
Mar 5, 2015 22:07
|
|