[HN Gopher] Swift Proposal: Move Function
___________________________________________________________________
Swift Proposal: Move Function
Author : todsacerdoti
Score : 71 points
Date : 2022-07-28 12:54 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pbardea wrote:
| Are there existing tools that help debug compiler time properties
| (e.g. reference counting) easily? I know of many interactive
| debugging techniques for investigating runtime errors, but when
| I'm faced with a compiler error it seems like the best interface
| I have is just an error message and then meticulously reading the
| code. I'd find something like that really useful for type-related
| errors too.
|
| Even something as simple as breakpoints and printlns let me
| inspect the intermediary state of these systems.
| dwaite wrote:
| Since reference counting is automatic for the most part, the
| language tries to express the semantics of references itself -
| for instance, you can capture self weakly for a callback later,
| and have to check that you still have a valid capture before
| use.
|
| After that, your issues then are typically reference cycles,
| which can really only be found by tooling at runtime or by
| certain linting tools (e.g. warn that the type definitions make
| reference cycles possible, even if your code isn't making
| cycles). There are tools such as Instruments included with
| Xcode to help detect cycles at runtime.
| Kukumber wrote:
| good idea, but it's stupid to put it in the standard library
|
| it should be built in
| Someone wrote:
| One of the stated goals is _which enforces this by causing the
| compiler to emit a diagnostic upon any uses that are after the
| move function_ , so they may say it will be part of the
| standard library, but the compiler will have to know what it
| does, just as a C compiler can assume what _strlen_ (if
| #included from the right system header) does and inline it any
| way it wishes.
| stephencanon wrote:
| Very, very little of the swift surface language is not part of
| the standard library. "Basic" types like `Int` and operations
| like `==` are defined in the standard library, rather than
| built-in.
| aaaaaaaaaaab wrote:
| Move should have been the default...
| dagmx wrote:
| Swift is ref counted so I'm not sure how having move semantics
| be the default would really work with that? If it weren't, I'd
| agree, but that was one of the core tenets of the language as a
| successor of ObjC
| p4bl0 wrote:
| What do you mean? Like using a variable automatically sets it
| as unusable anymore except if you opt-in to mark it as still
| usable? It kinds of remind me of linear logic, but wouldn't
| that be a real pain to program with?
| roblabla wrote:
| So, Rust has this very awesome thing where all variables are
| move by default, but _types_ may opt in to be copied by
| implementing the Copy trait (a trait being the Rust
| equivalent of a Swift protocol).
|
| This works _exceedingly well_. It essentially maps to what I
| want to do in almost all cases: Things that can trivially be
| copied (because they don 't contain a resource) will usually
| work as you'd expect in any other programming language, while
| things that cannot (because they contain a resource like a
| file descriptor, or an owned pointer to some allocated
| memory) will indeed mark the old variable as unusable.
|
| This is a really pleasant model to work with. So much so that
| I miss it terribly whenever I work in another language.
| thealistra wrote:
| I believe this was in the swift roadmap to have an opt-in
| borrow semantics for a block of code, if you want to do low
| level systems programming - just like rust.
|
| But I guess it didn't fit to migrate from current obj-c
| ecosystem so they left it for later.
| usrusr wrote:
| Even if we ignore ownership semantics for a moment, I find myself
| missing an explicit per-identifier end of scope ("undeclare")
| surprisingly often. The workaround is anonymous blocks, at least
| if you're one of those who don't like chopping up code into
| countless single-use functions. But that forces you to do early
| declaration when aiming for overlapping scopes and I really don't
| see a reason for this limitation. I guess the main reason for the
| absence of "undeclare" in most languages is that features
| affecting only local scope are beneath most language designers?
| ChildOfChaos wrote:
| Not sure what this means, but I'm learning Swift and SwiftUI
| right now, since i'm in the apple eco system and hoping i've made
| the right choice, because my time is fairly limited, being an
| adult in my late 30's and having a full time job, it does seem a
| bit of a mess though.
| drmidnight wrote:
| I too am in my late 30s and I've been writing Swift for 7 years
| now and the language itself is not buggy, at least anymore.
|
| SwiftUI has it's issues and one is platform support. If you
| want to support anything before iOS 13 (even that has limited
| support) then you are out of luck. The only SwiftUI I have
| shipped is for WidgetKit and WatchOS, both being somewhat
| forced upon you.
|
| While it can be cumbersome to do simple things in SwiftUI that
| were easy to do in UIKit, I haven't found too many bugs. Most
| issues I have run into are on the Xcode side.
|
| If you work with any Apple platform it is worth pursuing. If
| you want to just learn and use Swift it does have decent
| support on Linux thanks to being able to bind with C libraries.
| Windows support is there, but is very much in its infancy.
| herodotus wrote:
| I have a published App written in SwiftUI and I have written
| many thousands of lines of Swift. But I just scratch the
| surface of the language, and that is OK with me. There are many
| parts of the language that I almost certainly do not
| understand. But my code works, it runs fast and it does what I
| want. Yes, Swift does have a large "surface area" and that is
| too bad. But you can get by well without bothering with many of
| the darker parts.
| happytoexplain wrote:
| I think the fact that advanced features are available, but
| their existence doesn't impact most developers writing most
| apps, is a great thing. (Not that Swift - especially SwiftUI
| - is perfect.)
| scottiebarnes wrote:
| Don't worry, most consumer facing software development is a
| mess, there's constantly changing frameworks and shiny new ways
| of doing things.
| hbn wrote:
| I tried to get into learning Swift/UI several months back and
| was pretty disappointed how buggy the whole thing is, even when
| you're trying to do pretty basic things.
|
| It seems like a lot of the iOS veterans are still not
| interested in switching to it so who knows, maybe I'll come
| back to that in the future when it's actually production-ready
| like Apple claims it is.
| herodotus wrote:
| Strange, but this was not my experience. I found it took me a
| while to wrap my head around the way SwiftUI works, and the
| documentation was really bad. But buggy, not.
| skohan wrote:
| I wouldn't say I found it buggy, but rather limited. For
| instance even something simple like a list view has limited
| customisability, and some of the styling is mandatory
| unless you want to rebuild the entire component from
| scratch. It's a far cry from UITableView which can do just
| about anything.
|
| Also I found that once you get into stuff like animations,
| things get messy _very_ quickly since everything has to be
| expressed declaratively. It 's a nice idea for simple
| static views, but I really missed the ability to have
| separation of concerns the way you can with UIKit.
|
| Also I _did_ find the tooling quite buggy. Like certain
| things would break the preview, and not give meaningful
| errors or just crash the Xcode process, so I would have to
| fix it through trial and error with commenting out sections
| of code until it would work again.
|
| I am sure it will improve, but with UIKit you can basically
| achieve anything, and SwiftUI still seems like it has a lot
| to figure out.
|
| I think it's a shame FRP has basically won front-end at
| this time, because while it's been a revelation in web
| (since it solves a lot of the problems which make web a
| mess) it carries a lot of its own problems, and I think
| there are going to be a lot of apps which will be horrific
| to maintain over the next few years.
| ChrisMarshallNY wrote:
| I like the idea.
|
| It's a fairly fundamental change, though. I'm not a compiler
| person, so I don't know how much cheese it would move. It also
| may argue with some of the built-in optimizations.
|
| If you want to see these in action, run the symbolic debugger in
| release mode.
| anonymouse008 wrote:
| I have wasted many, many hours tracking down reference cycles,
| so in some sense, I welcome this change.
|
| However, the scope creep of Swift is becoming nightmarish -
| nothing just makes sense anymore.
|
| My hopes for Swift are that it teaches a whole generation how
| to program really compelling applications, full stack, in a
| profitable ecosystem (though open source, Swift is a 'gateway
| drug' to get people into the ecosystem). We will see if these
| decisions advance or detract from that.
| pixelrevision wrote:
| I had been feeling that way until I worked on a project that
| uses modern React and realized that a lot of other stuff is
| becoming this way. At least with Swift the compiler helps you
| along a lot and you can lookup most language concepts easily
| without them being so out of date.
|
| That said I really wish the tooling would keep up. Debugging
| stuff like SwiftUI and async/await code is really painful
| right now. It feels like they keep adding this stuff without
| updating the tools we need to have available to really
| support it. This is in stark contrast to what was/is
| available for Objective-C and UIKit with the debugger and
| instruments. I'm not sure it's a good tradeoff... The high
| level code becomes a lot easier to read and write but keeping
| a mental model of what's happening is a lot harder and it
| becomes very thorny when things go sideways.
| scarface_74 wrote:
| I live in the Apple ecosystem as a user. But as a developer,
| I could not imagine tying myself to it. It would put my
| career too much at the whims of Apple.
| ChrisMarshallNY wrote:
| Well, I have had my career pinned to it since 1986.
|
| It has not always been fun. Lots of atomic wedgies, in the
| recess yard, but things have worked out OK, in the long
| run.
| ChrisMarshallNY wrote:
| I have encountered very few of these, with Swift. The
| reference counter seems good.
|
| I tend to declare many of my object references as weak,
| anyway; even if not necessary.
|
| Of course, I'm old-fashioned (and I primarily work with
| UIKit), so I use classes a lot.
|
| If I am doing it the "current" way, most of the program uses
| value semantics, so it should not be an issue (in theory,
| anyway).
| anonymouse008 wrote:
| Aye - same here. Was once just a novice who had no idea how
| an application could hog up 62Gb of ram - and have weird
| changes to objects that shouldn't. Then I learned about
| references, and what a biological messaging system really
| means (thanks, Alan and NotificationCenter!).
| [deleted]
| georgelyon wrote:
| The move function is not move semantics (though the latter is
| being discussed by the community). The main purpose of the move
| function is to explicitly document where performance sensitive
| code depends on a specific type of compiler optimization and
| providing diagnostics if those conditions change in a subsequent
| revision of the code.
|
| Swift's focus on progressive disclosure means most Swift users
| won't need to worry about this.
| tambourine_man wrote:
| Swift's focus continues to be "how do we make the compiler
| happy to help it emit faster code" IMO. Very much in line with
| Lattner's, a compiler guy par excellence, original vision.
|
| Unfortunately for me, it's not aligned with my preferences. I
| like small languages and frameworks that I can master and build
| upon. Tough luck for me, of course, who cares.
|
| But I'm not convinced Swift is also aligned with what should be
| the language's main purpose: build great iOS and Mac apps.
| tambourine_man wrote:
| Lattner wanted it all: a language great at system
| programming, scripting and web framework and building apps.
| It's very ambitious and unheard of, but so was LLVM, so who
| knows, maybe he was onto something.
|
| 8 years later, it's safe to say it's not the language of
| choice for the new kernel or driver code, not the one for the
| hot new web framework and it's not replacing Python.
|
| The only thing it's got going for it is that it's the only
| officially supported choice for making iOS apps going
| forward. Ultimately, no one uses Swift voluntarily, and
| that's a bad sign.
|
| I write all of this with sorrow, I was cheering with joy when
| Swift was released.
| wwalexander wrote:
| I personally love Swift and find it a joy to use. To be
| fair, I'm ultimately doing {i,mac}OS dev with it [1] but
| the parts that actually touch SwiftUI/UIKit/AppKit are just
| a small part, and I usually start by writing packages with
| all the business logic/model data.
|
| I write Go for work and my all-time favorite language is
| probably still Rust, but I find that a ton of really
| thoughtful and smart choices have gone into Swift-the-
| language as well as how it's used to build apps.
|
| Happy to expand more on what I like about using Swift if
| you're curious.
|
| [1] which you can now write as the same codebase using
| SwiftUI
| ezfe wrote:
| > Ultimately, no one uses Swift voluntarily, and that's a
| bad sign.
|
| Not true for me, I've used it successfully for server side
| work. Being able to use the same language is nice since I
| can pull in the same routines/data structures and not re-
| implement them.
| vips7L wrote:
| > a language great at system programming, scripting and web
| framework and building apps.
|
| Sounds like D.
| mojuba wrote:
| > Ultimately, no one uses Swift voluntarily, and that's a
| bad sign.
|
| Sorry but this can't be more wrong. I love Swift so much
| that I can tolerate and forgive its compiler's
| sluggishness.
|
| Swift is now available on Linux (has been for a while) and
| there's Apple's server framework called SwiftNIO. It's
| designed for fast and efficient multithreaded server-side
| code. I _voluntarily_ picked it for my next backend project
| and am very happy so far.
| jamil7 wrote:
| > Ultimately, no one uses Swift voluntarily
|
| I would use it in more places if I could, it's a language I
| feel extremely productive in. Apple however has shown zero
| interest in helping popularise it anywhere outside of their
| ecosystem and left it up to the community.
| skohan wrote:
| You could even say they're basically hostile to it.
| pjmlp wrote:
| Apple stated at WWDC that is now being used on system level
| on Ventura.
|
| They also dedicated some time on the state of the
| frameworks session, to put it clearly out there that
| Objective-C is done and it is time to move on.
|
| It took about 20 years for C++ to take over some key areas
| to C, and even there it wasn't a success in POSIX and
| embedded, where C still rules.
|
| 8 years isn't nothing.
| TheTon wrote:
| I had hoped ObjCs successor for app development would be
| something like FScript. Something that removed the footguns
| and unnecessary ceremony from ObjC but that had good interop
| with existing code.
|
| Instead we got Swift, which ironically, given its uptake by
| external devs, I think was aimed at complaints from internal
| Apple users. Internal users at Apple were frustrated by how
| easy it was for external devs to introspect and modify
| private ObjC framework code. They also wanted performance
| features like value types and method inlining.
|
| I don't think many external app devs cared about those
| things, or to the extent they did C++ was an attractive
| option because a stable ABI doesn't really matter internal to
| application code.
|
| I continue to use ObjC for Mac and iOS dev because it's a
| much simpler language than Swift, the system APIs I interact
| with are still implemented in ObjC, and C++ interop is easier
| via ObjC++. I suppose the day will come where I need
| something that is only accessible from Swift, and I'll write
| Swift then, but for now Swift doesn't solve any problems that
| I have.
| thealistra wrote:
| I was very happy when swift was introduced and it solved
| many classes of bugs that were very popular in Obj-C. It
| was very much a big help for external developers.
|
| Swift apps are not crashing randomly, you don't have nils
| running rampant because of type safety.
|
| You can create types that nicely convey reality using rich
| enums and you don't have to define objects with 18 fields
| that are mostly always nil, but when propertyA == 16, then
| this field has some value.
|
| Swift also is not an official superset of C, like
| Objective-C, so you don't have all the footguns of C
| language, like integer promotions and assignment being an
| expression.
|
| You just have so much improvements over objective-C if you
| want to ship an app to hundreds of thousands of users and
| be sure that it works correctly and that unhandled edge
| cases won't blow up.
|
| Maybe it is more complex to write a compilable piece of
| swift, that a compilable piece of Objective-C, but I am
| happy that this is the case, because it means that the
| compiler has my back and finds bugs and issues for me.
| skohan wrote:
| I actually see it in the exactly opposite way. A couple years
| ago, Swift was a nicely designed language, with a manageable
| number of composable features which could be used to do just
| about anything.
|
| With the features which were released alongside SwiftUI, it
| seems like that went out the window, and Swift pivoted
| towards being a DSL for iPhone apps.
| kaba0 wrote:
| I honestly don't understand what were they thinking. Choose
| a random language's random feature and swift has it. That's
| hardly a good thing for a programming language, and it
| shows -- there are some very nasty interactions between
| different features.
| skohan wrote:
| I still think there's a lot to like about Swift, and
| actually programming in some subset of Swift is some of
| the most fun and expressive programming I can think of,
| but it has undoubtedly become kind of a mess. A lot of
| magic happening, and not in a good way.
| kaba0 wrote:
| I agree, I was very enthusiastic at the beginning of
| learning it. And if nothing else, it is a great refresher
| of Pl features.
|
| I'm just afraid that the language can't be properly
| maintained from the insane matrix of all these features
| (I once got a type inference timed out error..)
| pohl wrote:
| I find it difficult to empathize with that reaction. Other
| languages have complicated corners that I can safely
| ignore, why not Swift?
|
| Rust has its macros, Swift has its result-builders.
|
| The latter wins a nice way to declaratively-describe UI
| widgets, but if that's not what I'm doing I don't need to
| think about it.
| skohan wrote:
| It's not about the features it's about priorities. In
| principal as you say you can just ignore the bits you
| don't use, but there are still some glaring holes like
| variadic generics which didn't get attention presumably
| because the core team was focused on SwiftUI.
|
| And due to the governance of the language, the
| "community" priorities will always take a back seat to
| Apple's product priorities, so it feels a bit funny to
| invest too heavily in the language for that reason alone.
| pohl wrote:
| Thank you for elaborating, that does help me appreciate
| your point of view better. I personally prefer that they
| prioritized result builders higher -- I guess I agree
| with them that the needs of the UI layer were more
| urgent.
|
| It would be nice to have variadic generics, though.
| pjmlp wrote:
| The language main purpose was always to be a replacement for
| C, C++ and Objective-C.
|
| It has been on Swift documentation from day one.
| tambourine_man wrote:
| Officially stated goal, sure.
|
| But read/listen to Lattner says and you get a different
| take.
| xbar wrote:
| This is a helpful clarification.
| jordanmorgan10 wrote:
| Swift epitomizes easy to pickup, difficult to master.
___________________________________________________________________
(page generated 2022-07-28 17:00 UTC)