|
In this case, Joe and I literally had that conversation in the public Swift JIRA instance.
|
# ? Jun 12, 2016 19:33 |
|
|
# ? Jun 5, 2024 08:50 |
|
Since I am obsessive about having no warnings at all, how do I solve this one?:code:
but if I do that, I get: let pattern cannot appear nested in an already immutable context Edit: here's the entire func: code:
|
# ? Jun 12, 2016 19:47 |
|
If you leave off the var, it will implicitly be a constant: for c in rowsColumns.characters
|
# ? Jun 12, 2016 20:12 |
|
Wait what. Value type Foundation-equivalents weren't announced before just now, were they? (The Date/DateComponents/etc stuff?)
|
# ? Jun 13, 2016 22:59 |
|
That went through the standard swift-evolution process and has been in the preview toolchain builds.
|
# ? Jun 13, 2016 22:59 |
|
Yup, all the Swift 3 stuff has been part of the normal process.
|
# ? Jun 14, 2016 04:01 |
|
Yeah I found the proposal. I don't know how I missed it.
|
# ? Jun 14, 2016 04:10 |
|
Am I doing something dumb? Why is String.hash returning Int? Shouldn't it be UInt?
|
# ? Jun 14, 2016 19:04 |
|
TheReverend posted:Am I doing something dumb? Why is String.hash returning Int? Shouldn't it be UInt? Pretty sure that's because Swift imports NSUInteger as Int.
|
# ? Jun 14, 2016 19:38 |
|
Hey Swift Gang. I've been working as an automation engineer for the last five years but over the last few months I've fallen in love with iOS development with swift. I have a few projects up on github and a app in the store. What are some things I could learn to set myself apart from the pack when I start interviewing for a proper swift / iOS position in the next month or two? I can provide a resume and github over PM. Don't really want to out myself in this thread.
|
# ? Jun 17, 2016 02:16 |
|
Experience using different frameworks and their quirks is what really sets someone apart. Hard to cram for that though. Having stuff on github is a good first step. One thing I see is that even though Swift is getting pretty prevalent, architecture questions I see still focus on patterns that are more heavily used in Obj-c. Maybe checking some obj-c design patterns (look for acronyms like KVO/KVC/Delegation etc)
|
# ? Jun 17, 2016 02:25 |
|
Start interviewing now, learn up on whatever you encounter.
|
# ? Jun 17, 2016 03:02 |
|
Thanks for the advice! I'm going to run through The Big Nerd Ranch Objective-C book over the next couple of days so I can familiarize myself with some of the older patterns and understand obj-c code a bit better. Then I'll start tossing the resume out and get into it.
|
# ? Jun 17, 2016 07:02 |
|
I'm trying to build a tiny new Swift 3.0 MacOS app to profile and I'm getting a compiler error...it builds fine without warning running it generally but as soon as I build for profiling I get the following error...code:
Edit to add: I've deleted code all the way down to just the ViewController stub you get for SpriteKit apps and I still get the error toiletbrush fucked around with this message at 22:25 on Jul 5, 2016 |
# ? Jul 5, 2016 22:20 |
|
That's not a really an error; it's a compiler crash that printed a relatively nice-looking diagnostic before aborting. Anyway, I recognize that one, and while I can't remember if there's a workaround, It should be fixed in the next beta.
|
# ? Jul 6, 2016 02:18 |
|
This may not be the most correct place to ask, but stack overflow and google in general have failed me. For iOS 9.2 > with the multitasking stuff came a new public property on AVPlayerViewController - allowsPictureInPicturePlayback which does just what it sounds like. What I need to know is - since that is now a public property - is there a way to turn it on/off from Javascript? Like - a way to pass parameters to the play as you're playing a video, from an html player, for example. I am able to listen for webkitpresentationmodechanged to grab webkitPresentationMode which returns a value of 'picture-in-picture' but disabling the event bubble from there is causing the page to freeze after you exit fullscreen. If possible, I'd rather just hide the PiP button altogether. TIA
|
# ? Jul 11, 2016 19:32 |
|
So Matt Gallagher makes an interesting argument that Swift's type constraint system solver can be made linear time instead of exponential, eliminating the stupid "expression too complex to type check" error. http://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html He freely admits that he isn't qualified to say whether his proposed solution is good enough or has fatal flaws. Frankly I'm not qualified to make that judgement either. I was hoping rjmccall or someone else with compiler type system experience could shed some light?
|
# ? Jul 19, 2016 03:38 |
|
Ender.uNF posted:So Matt Gallagher makes an interesting argument that Swift's type constraint system solver can be made linear time instead of exponential, eliminating the stupid "expression too complex to type check" error. That's my post that he links near the end. Exponential worst-case behavior is inherent to the type system, but I'm not sure how he gets from there to the idea that the compiler team isn't interested in type-checker improvements, since my post actually mentions at least one type-checker improvement that I implemented as part of my analysis (and there were several others). As for concrete feedback, his algorithm isn't really an algorithm. Phase 1 in particular "eliminates" type variables by building arbitrarily complex types apparently defined by arbitrarily complex compound, nested constraints. The other idea, merging disjunctions, is a good one and, in fact, one we've already considered and would like to try. The problem is that we just haven't had the time to flesh it out because, unfortunately, the people who most understand the type checker are senior engineers with a lot of other responsibilities, like managing the team or making sure other features get implemented. We've recently brought in another engineer to work on it, but honestly I'm not even sure the expression type-checker is our first priority, because there's a lot of lost performance in other parts of semantic analysis.
|
# ? Jul 19, 2016 05:04 |
|
I thought default public non-subclassability was sensible, but apparently bureaucratic forces are just restricting my freedom without reason or purpose. I'm grateful that people on the mailing list have opened my eyes.
|
# ? Jul 20, 2016 18:02 |
|
Toady posted:I thought default public non-subclassability was sensible, but apparently bureaucratic forces are just restricting my freedom without reason or purpose. I'm grateful that people on the mailing list have opened my eyes. That dude is really starting to tick me off, and I don't mind saying so in a public forum.
|
# ? Jul 20, 2016 18:15 |
|
If it's who I think you're talking about and their name rhymes with poo I met this person at a local Swift meetup and they are ...rather passionate.
|
# ? Jul 20, 2016 18:30 |
|
it's a very strange thing to get het up about, since unless you actually *forbid* nonvirtual methods people who care about api design will still be designing their inheritance contracts accordingly.
|
# ? Jul 20, 2016 19:57 |
|
Would have been better off not open sourcing the language.
|
# ? Jul 20, 2016 21:00 |
|
The guy I'm thinking of (not rhymes-with-poo guy) is the one who goes only by his first initial and last name. I think I've seen him make one constructive post in the few months I've been following swift-evolution. Everything else is just meandering word salad that I can't even begin to parse and I don't think it's just a language barrier/non-native speaker problem. Someone should write a proposal banning him. I don't see why everyone is so up in arms about sealed-by-default classes anyway. You already can't subclass value types, and I've found myself writing way more of those than class types nowadays. And the class types I *do* write tend to be just because I need reference semantics and I make them final anyway. People complaining that they need to be able to subclass to "fix bugs" are poo poo out of luck if they have a struct, and that's a terrible justification/use for inheritance anyway. I'm glad the core team feels really strongly about this one so it doesn't get derailed. No matter, I'm just glad my proposal finally got accepted!
|
# ? Jul 20, 2016 22:16 |
|
Flobbster posted:And the class types I *do* write tend to be just because I need reference semantics and I make them final anyway. Just jumping in without any knowledge of the discussion, but final is so much more performative I'm not surprised at sealed-by-default.
|
# ? Jul 20, 2016 22:24 |
|
Flobbster posted:I don't see why everyone is so up in arms about sealed-by-default classes anyway. You already can't subclass value types, and I've found myself writing way more of those than class types nowadays. And the class types I *do* write tend to be just because I need reference semantics and I make them final anyway. People complaining that they need to be able to subclass to "fix bugs" are poo poo out of luck if they have a struct, and that's a terrible justification/use for inheritance anyway. I'm glad the core team feels really strongly about this one so it doesn't get derailed.
|
# ? Jul 20, 2016 22:44 |
|
rjmccall posted:That dude is really starting to tick me off, and I don't mind saying so in a public forum. I have reservations about the proposal, but, man, he's so irritating I almost wanted it to get approved out of spite.
|
# ? Jul 20, 2016 23:44 |
|
Plorkyeran posted:AFAICT most of the people opposed to it don't actually use Swift and only care about what happens to Swift because they assume they'll be forced to use it in the future, so they won't have noticed that sort of thing. This explanation is one I've heard brought up in conversation before and it would make a ton of sense. It seems like there's a decent number of community members who are using the project as a vanity-contribution opportunity where they can argue about aesthetics, despite not really using the language.
|
# ? Jul 21, 2016 00:01 |
|
One of the reasons that's a read-only mailing list for me. You've got to have skin in the game.
|
# ? Jul 21, 2016 01:20 |
|
So I have some aliases in ~/.lldbinit that work fine. However, when I run them automatically on app-launch via a breakpoint, they spit out errors complaining about @ preceding strings and whatnot. Why is this and how do I fix it :[
|
# ? Jul 21, 2016 03:19 |
|
Guess: trying to run objc in a swift context. Try sticking some -l objc++ after your command (e.g. expr -l objc++).
|
# ? Jul 21, 2016 03:39 |
|
Well, here goes Round 4. 3? 6? I can no longer recall what sort of time it was before I wandered this desert.
|
# ? Jul 21, 2016 07:50 |
|
pokeyman posted:Guess: trying to run objc in a swift context. Try sticking some -l objc++ after your command (e.g. expr -l objc++). I'll give that a shot tomorrow. It's weird though that it would complain when using the exact same command in the exact same place. If I hit my breakpoint and manually type poo poo in, it works.
|
# ? Jul 21, 2016 07:56 |
|
rjmccall posted:Well, here goes Round 4. 3? 6? I can no longer recall what sort of time it was before I wandered this desert. Oh man, how was that "over two and a half hours" of nerd-talking about semantics?
|
# ? Jul 21, 2016 15:48 |
|
ultramiraculous posted:Oh man, how was that "over two and a half hours" of nerd-talking about semantics? It was Wednesday.
|
# ? Jul 21, 2016 16:50 |
|
Toady posted:I thought default public non-subclassability was sensible, but apparently bureaucratic forces are just restricting my freedom without reason or purpose. I'm grateful that people on the mailing list have opened my eyes. For those of us who don't have the time to follow the mailing list, can someone elaborate on what's going on here?
|
# ? Jul 21, 2016 18:38 |
|
I linked the latest proposal. The idea is that making a class public shouldn't by itself allow it to be subclassed externally, and making a method public shouldn't by itself allow it to be overridden externally. Those should be additional, opt-in capabilities. In an earlier proposal, we suggested calling this "public open"; now we're just suggesting "open" so that it's more of an even alternative. None of this will impact Cocoa; everything from ObjC will still be considered open by default. The basic breakdown is that library authors really like it, but other people are worried that they won't be able to get their work done (at least the way they're used to) because libraries will be too locked down, and some in the second camp are really over-the-top about it.
|
# ? Jul 21, 2016 18:52 |
|
Also people saying how "but this is how we work around bugs in apple's frameworks, we'll be totally stumped without this" miss that - Apple will do this anyway, even if it's not the language default - you already can't do it with structs - they aren't as smart as they think they are and poo poo will break
|
# ? Jul 21, 2016 19:13 |
|
rjmccall posted:I linked the latest proposal. That's what I get for leaving the thread open for several hours and replying without refreshing Though I always did think the "subclass it and change it to break it further until it works again" was a bad pattern, so I think this is a good change. But I also tend to prefer using the lower-level frameworks whenever possible, instead of the higher-level frameworks that seem to need "fixing" more often.
|
# ? Jul 21, 2016 20:33 |
|
|
# ? Jun 5, 2024 08:50 |
|
man, "public open" made way more sense than the accessibility default magically changing when you un-final the type :/
|
# ? Jul 21, 2016 20:35 |