Just one more thing - Swift thread - The Something Awful Forums

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›48 »

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Plorkyeran posted:

I think the C API currently just exposes the IDE support functionality, which is basically just "tokenize this string" and "tell me about whatever's at this offset". For an AST you'd have to access the guts of the implementation (for Swift Jazzy just tokenizes the file then does the equivalent of alt-clicking each token and then reconstructing the structure).

Yeah, jazzy/SourceKitten is basically all I've found as reference for people using SourceKit. Mostly, as someone who worked on an Xcode alternative for most of the last year, I somehow wasn't expecting an even more uphill battle than dealing with python-lldb.

edit: And obviously this is coming from someone wanting to skim the AST of a language nobody knew about 18 months ago, so take my complaints lightly, rjmccall.

ultramiraculous fucked around with this message at 07:44 on Jan 5, 2016

# ? Jan 5, 2016 07:40

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 23:33

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Well there's a few other projects built on sourcekitten, but obviously they'll all just use the same bit of SourceKit functionality so they aren't very interesting.

# ? Jan 5, 2016 16:56

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

If you just want to explore the AST yourself and don't care about doing it programmatically, there are secret compiler command line flags like -print-ast. Otherwise, SourceKit patches welcome.

# ? Jan 5, 2016 18:10

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

I'm playing around with dead stripping and Swift since I'm working on something where I might be generating a large amount of code for a library but want the linker to be able to kill anything that the user doesn't actually call. Here's my problem: -dead_strip doesn't seem to work if things are declared public.

I created a two-file test case to whittle it down. strip.swift has two functions:

code:

func foo() { print("foo") }
func bar() { print("bar") }

and main.swift:

code:

bar()

So I would expect foo() to be stripped since it's never used. When both functions are declared internal, like above, it works: foo is nowhere to be found in the executable. But, if I declare foo and bar to be public, the linker no longer strips foo out.

Here's my swiftc invocation:

code:

swiftc -o strip -Ounchecked strip.swift main.swift -Xlinker -dead_strip

It kind of makes sense that public things wouldn't get stripped since they might be needed elsewhere in the general case, but this case is surprising since it's linking into an executable so it's not going to be linked into something else that would try to use that function. Should I expect this behavior? Is this even a Swift problem, or a limitation in the linker?

Adding -whole-module-optimization doesn't have any effect, either.

Flobbster fucked around with this message at 23:35 on Jan 11, 2016

# ? Jan 11, 2016 23:25

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Flobbster posted:

It kind of makes sense that public things wouldn't get stripped since they might be needed elsewhere in the general case, but this case is surprising since it's linking into an executable so it's not going to be linked into something else that would try to use that function. Should I expect this behavior? Is this even a Swift problem, or a limitation in the linker?

I think Swift might be forcing the symbol to be emitted if it's public in a way that suppresses linker dead-stripping, as if the function was marked with __attribute__((used)). I agree that that's unfortunate in this case.

# ? Jan 12, 2016 02:03

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Flobbster posted:

It kind of makes sense that public things wouldn't get stripped since they might be needed elsewhere in the general case, but this case is surprising since it's linking into an executable so it's not going to be linked into something else that would try to use that function.

This isn't strictly true, as with great care it's possible to dlopen() mach-o executables. Exporting all public symbols from an executable shouldn't be the default, though...

# ? Jan 12, 2016 04:44

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

rjmccall posted:

I think Swift might be forcing the symbol to be emitted if it's public in a way that suppresses linker dead-stripping, as if the function was marked with __attribute__((used)). I agree that that's unfortunate in this case.

Bummer, thanks. I filed SR-521 just to see if there's any chance of improving this, since it might cause code bloat problems for my use case.

Plorkyeran posted:

This isn't strictly true, as with great care it's possible to dlopen() mach-o executables.

People who do that are jerks! (I've done this

)

# ? Jan 12, 2016 04:52

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Are you supposed to be able to override final methods that are implemented in protocol extensions? A coworker and I were playing around with a mixin-y deal and were surprised that the compiler would let a class override something finalized in a protocol extension.

For example something like this seems like it shouldn't work:

code:

protocol ThingProvider {
    var thing: String { get }
    
    func performAThing()
}

extension ThingProvider {
    final var thing: String { return "Real Deal" }
    
    final func performAThing() { print(thing) }
}

class Overrider: ThingProvider {
    // Causes `performAThing` to print "Not The Same"
    var thing: String { return "Not The Same" }
}

# ? Jan 26, 2016 01:38

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

I don't know why we let you write final on things in protocol extensions.

# ? Jan 26, 2016 01:55

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Really? It seems an at least semi-legit thing to do...?

# ? Jan 26, 2016 02:07

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

They're really not mix-ins, although I will admit they're being used that way.

# ? Jan 26, 2016 05:41

Doctor w-rw-rw-: Jun 24, 2008

I have to update to 10.11 to get the latest, hopefully-non-segfaulting version of the Swift compiler?

*whines*

# ? Jan 30, 2016 01:58

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Doctor w-rw-rw- posted:

hopefully-non-segfaulting

Well, don't get your hopes up.

# ? Jan 30, 2016 03:55

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

rjmccall posted:

Well, don't get your hopes up.

Can you go over to dev tools and smack whoever broke the SourceKit notification banner? I've been getting massive numbers of crashes (especially when it involves generics and type inference) which wouldn't be so bad... except now Xcode has a ~40% chance of crashing when SourceKit crashes. I'm back to restarting Xcode multiple times per hour.

Not directed at you: There also appears to be a huge impedance mismatch between SourceKit as Xcode uses it and the real compiler because I get no autocomplete in my framework unit test target (all types from the framework itself import as <<error type>> but everything compiles and runs just fine). Unfortunately trying to replicate this in a sample project failed - everything works - so there is something about larger projects or more complex dependencies that I haven't been able to diagnose. Funny enough the main app and it's unit test target don't have this problem. I haven't filed a radar because I don't have anything useful to provide besides "hurrrr broken".

# ? Jan 30, 2016 05:48

Doctor w-rw-rw-: Jun 24, 2008

https://swift.org/blog/swift-api-transformation/ posted:

Swift code:

class UIBezierPath : NSObject, NSCopying, NSCoding { ... }
...
path.addLineToPoint(CGPoint(x: 100, y: 0))
path.fillWithBlendMode(kCGBlendModeMultiply, alpha: 0.7)

and after:

Swift code:

class UIBezierPath : Object, Copying, Coding { ... }
...
path.addLineTo(CGPoint(x: 100, y: 0))
path.fillWith(kCGBlendModeMultiply, alpha: 0.7)

Good lord, this is awful. Is addLine(toPoint:) not clearly better than deleting the context outright?

rjmccall, please find whoever thought the 'after' is an improvement and slap them (not a serious suggestion). I honestly cannot figure out why someone would go "oh hey, I have a good amount of context on exactly what this method should do. What a shame; we should get rid of that."

# ? Jan 30, 2016 19:24

nah thanks: Jun 18, 2004; Take me out.

Doctor w-rw-rw- posted:

I honestly cannot figure out why someone would go "oh hey, I have a good amount of context on exactly what this method should do. What a shame; we should get rid of that."

I agree. One of the things I actually love about Cocoa is the verbosity of the APIs, and how the method names make it completely obvious what they do and how to use them. It makes reading other people's code, or my own old code, so much less painful.

This just seems like brevity for brevity's sake. I don't like it at all.

# ? Jan 30, 2016 20:14

Echo Video: Jan 17, 2004

well how often is it just gonna end up like path.addLineTo(nextPoint)

e: counterpoint

Echo Video fucked around with this message at 20:21 on Jan 30, 2016

# ? Jan 30, 2016 20:19

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

I'll be honest... I don't see the point either. I guess it removes some verbosity but I'd rather people spent time on concurrency or improved reflection support but whatever.

# ? Jan 30, 2016 20:41

brap: Aug 23, 2004; Grimey Drawer

I assume that tweaking the automatic method name conversion is not being pursued to the exclusion of things we really care about.

That said, "The Great Swift API Transformation" implies much more significant things than "we changed the names of methods." I was expecting that the post would reveal something like "Cocoa methods that used to consume selectors can now consume closures" and things of that nature. The API taking full advantage of the language features.

# ? Jan 30, 2016 20:47

Doctor w-rw-rw-: Jun 24, 2008

So, separate question - what's the best way for me to do SSL in a cross-platform way? I'm writing async network stuff using GCD dispatch sources + sockets directly, and I want to layer SSL atop it.

GnuTLS? NSS? I know Secure Transport and Common Crypto are open-source, but I don't know whether they've gotten Swifty, so to speak. Are they candidates for either inclusion with or porting to Swift, or would export restrictions restrain that?

# ? Jan 30, 2016 21:18

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

The effort this year is to nail down a lot of things about the existing language to the point where source and binary compatibility become something we're willing to seriously discuss. That doesn't preclude language features; for example, part of why we're taking on property behaviors is specifically to figure out where we want go with that feature space and how much language/runtime support it needs. But it does mean that we have to treat these naming issues with the attention they deserve.

There are things I dislike about the Great Renaming, but dropping generic, redundant labels like "object" and "point" isn't really one of them.

As a meta point, I'm happy to report things like "Some developers have very strong negative reactions to removing nouns that restate argument types from method names" at the core team meetings, and I'm definitely happy to talk things through with you all here, we are an open source project now. Posting to swift-evolution and commenting on proposals are much more effective ways to shape things.

# ? Jan 30, 2016 22:53

Doctor w-rw-rw-: Jun 24, 2008

rjmccall posted:

There are things I dislike about the Great Renaming, but dropping generic, redundant labels like "object" and "point" isn't really one of them.

Basically, there are things I dislike about the Great Renaming, ~~but~~ and dropping ~~generic, redundant~~ clear, readable labels like ~~"object"~~ "withObject:" and ~~"point"~~ "toPoint" ~~isn't really~~ is definitely one of them.

rjmccall posted:

As a meta point, I'm happy to report things like "Some developers have very strong negative reactions to removing nouns that restate argument types from method names" at the core team meetings, and I'm definitely happy to talk things through with you all here, we are an open source project now. Posting to swift-evolution and commenting on proposals are much more effective ways to shape things.

I hate when people (read: HN users) pile on to (for example) GitHub issues and offer comments without committing to a discussion and end up adding noise instead of useful commentary, so I'm not really willing to participate directly since I'd prefer to be writing code or ~~poo poo~~posting/discussing here instead of ignoring/forgetting to participate elsewhere. FWIW, I'm fine with my post being excerpted or reposted elsewhere, if it's actually worth sharing.

For me, it's less about restating the types and more about losing the preposition. Take -convertPoint:toLayer:, -convertPoint:fromLayer, and -convertRect:toLayer:, for example. Sure, you could overload it so you have convert(_:, to:) and convert(_:, from:), but now you're not just removing redundancy, you're killing vital context. Using let allows you to not have to restate obvious type information, but let a = someThingThatReturnsACGPoint followed by convert(a, someLayer) is now stupidly ambiguous. convert(a, to:someLayer) is less stupidly ambiguous, but it's still ambiguous, because now there's no hint (my obtuse naming aside) that it's converting a point and not a rect.

So, again, two parts make it suck: a) apparent loss of useful prepositions, and b) loss of any hint because 'let'/'var' eliminates most of the actual bad redundancy. The method names are good redundancy because they're there for context-independent readability.

EDIT: and I may also be missing the point that prepositions wouldn't be removed, simply moved outside to the method name rather than being left in the parameter. I don't like this because for one thing, moving it to the method name can only really accommodate a single parameter name, and second, I value that the method names with different parameters create a much more natural grouping of similar methods. I can see the obvious counterargument, though.

Doctor w-rw-rw- fucked around with this message at 23:25 on Jan 30, 2016

# ? Jan 30, 2016 23:21

Gul Banana: Nov 28, 2003

cocoa's explicit method names were useful in a more dynamic language and time, where messaging was rarely or barely type-checked. if xcode's completion and overlays for swift have finally stabilised, the types in the function signatures will be a better guide than verbose naming ever was, and the names become redundant.

this is kind of an extreme version of the anti-comment argument - names shouldn't repeat or attempt to informally specify information which can be *verifiably* encoded as types.

# ? Jan 30, 2016 23:34

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

I would certainly agree that an API that's significantly overloaded by type, particularly a conversion API, should be an exception to the general rule. I don't think it makes sense to generalize from that, though.

# ? Jan 30, 2016 23:42

Doctor w-rw-rw-: Jun 24, 2008

Gul Banana posted:

cocoa's explicit method names were useful in a more dynamic language and time, where messaging was rarely or barely type-checked. if xcode's completion and overlays for swift have finally stabilised, the types in the function signatures will be a better guide than verbose naming ever was, and the names become redundant.

this is kind of an extreme version of the anti-comment argument - names shouldn't repeat or attempt to informally specify information which can be *verifiably* encoded as types.

Until clang can feed my eyes and brain type metadata directly, I'l take the redundancy, because it's information I'd otherwise have to expend effort to view anyhow, which gets in the way of scanning a great deal of code very quickly and intuitively discriminating between similar methods when debugging code.

:colbert:

Losing the visual information takes away a tangible part of Swift's appeal to me, because it's just making it hard for me to quickly correlate things.

# ? Jan 30, 2016 23:43

lord funk: Feb 16, 2004

fillWith()

# ? Jan 31, 2016 00:12

lord funk: Feb 16, 2004

Doctor w-rw-rw- posted:

I'l take the redundancy, because it's information I'd otherwise have to expend effort to view anyhow

1000x this. Might as well go full Java and have to look at method declarations to figure out what the arguments are.

# ? Jan 31, 2016 00:14

nah thanks: Jun 18, 2004; Take me out.

rjmccall posted:

The effort this year is to nail down a lot of things about the existing language to the point where source and binary compatibility become something we're willing to seriously discuss. That doesn't preclude language features; for example, part of why we're taking on property behaviors is specifically to figure out where we want go with that feature space and how much language/runtime support it needs. But it does mean that we have to treat these naming issues with the attention they deserve.

There are things I dislike about the Great Renaming, but dropping generic, redundant labels like "object" and "point" isn't really one of them.

As a meta point, I'm happy to report things like "Some developers have very strong negative reactions to removing nouns that restate argument types from method names" at the core team meetings, and I'm definitely happy to talk things through with you all here, we are an open source project now. Posting to swift-evolution and commenting on proposals are much more effective ways to shape things.

I don't have much to add aside from what I posted earlier, and what Doctor w-rw-rw- and Lord Funk are saying above (which I strongly agree with), but I did want to say thanks for the constructive reply, and for being super cool in this thread.

# ? Jan 31, 2016 00:16

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

I just discovered something weird, completely by accident. Apparently like class/struct properties, regular ol' local variables can have getters/setters. So you can do stupid poo poo like this:

code:

    var _x: Int = 0
    // we're at global scope, yo
    var x: Int {
      get {
        print("getting x, it's \(_x)")
        return _x
      }
      set {
        print("setting x to \(newValue * 2)")
        _x = newValue * 2
      }
    }

    x = 8

    func foo(inout x: Int) {
      print("entering foo")
      x = x + 5
      print("leaving foo")
    }

    foo(&x)

code:

setting x to 16
getting x, it's 16
entering foo
leaving foo
setting x to 42

Is this intentional? I wonder if there are any obscure and unwise tricks you can do with this.

# ? Jan 31, 2016 00:34

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Flobbster posted:

Is this intentional? I wonder if there are any obscure and unwise tricks you can do with this.

The answer is always yes. No one expects ~~the spanish inquisition~~ globals to be side-effecting getters/setters.

# ? Jan 31, 2016 01:36

Gul Banana: Nov 28, 2003

tbh going "full java"/.net is what i like about the change. i suppose reaction is going to vary by direction of entry to the language (though i was an objc programmer once in days of yore)

# ? Jan 31, 2016 01:47

Toady: Jan 12, 2009

squidgee posted:

I agree. One of the things I actually love about Cocoa is the verbosity of the APIs, and how the method names make it completely obvious what they do and how to use them. It makes reading other people's code, or my own old code, so much less painful.

This just seems like brevity for brevity's sake. I don't like it at all.

As an opposing view, I'm burned out from the verbosity of Objective-C APIs and find it a real chore at times.

# ? Jan 31, 2016 03:32

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Flobbster posted:

Is this intentional?

Yep. Other than property-behavior treatments like lazy, it's probably not the most useful/well-advised thing, but it does pretty much just fall out of the language.

# ? Jan 31, 2016 04:14

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Toady posted:

As an opposing view, I'm burned out from the verbosity of Objective-C APIs and find it a real chore at times.

Agreed. I'm happy not to feel the need to add a bunch of newlines in my method calls and line up the precious colons. Most Swift calls fit nicely on one line.

# ? Jan 31, 2016 04:23

Doctor w-rw-rw-: Jun 24, 2008

While on the topic of Swift language features, what is your opinion on language support for inline composition of object hierarchies?

Specifically, I mean JSX-like syntax, but without necessarily implying support for XML � perhaps just something that would make a library to implement a DSL like that possible. Easy inline composition of object hierarchies is very useful for inline markup of UI components / views. Android's UI format is literally XML, but not inline whereas React's is a simple XML-like syntax.

(I ask because Swift doesn't strike me as the kind of language where third party support for it would be particularly tractable, whereas an interpreted language with sourcemaps like JS does.)

# ? Jan 31, 2016 08:04

jawbroken: Aug 13, 2007; messmate king

Doctor w-rw-rw- posted:

Good lord, this is awful. Is addLine(toPoint:) not clearly better than deleting the context outright?

rjmccall, please find whoever thought the 'after' is an improvement and slap them (not a serious suggestion). I honestly cannot figure out why someone would go "oh hey, I have a good amount of context on exactly what this method should do. What a shame; we should get rid of that."

Scrolling through these shows 95% of uses have inline CGPoint constructor, and the remainder are generally variables with an obvious name (point, origin, etc). The proposed API changes look great.

# ? Jan 31, 2016 12:31

lord funk: Feb 16, 2004

jawbroken posted:

Scrolling through these shows 95% of uses have inline CGPoint constructor, and the remainder are generally variables with an obvious name (point, origin, etc). The proposed API changes look great.

It sounds like the argument you're making (and what the changes are banking on) is using variable names to supply method context. What a terrible idea.

fillWith(.Add)

Just gonna fill this thing with some Add.

# ? Jan 31, 2016 15:50

Kallikrates: Jul 7, 2002; Pro Lurker

I also think the point examples are a little too simplistic as lord funk shows. We're told to remove as much redundant type info and rely on inference as much as possible.
string.writeTo(filePath, atomically: ...)
Scanning that code 6 moths from now I am definitely not going to remember if filePath was a URI or String. If I have to fall back to hungarian notation-ish I think readability/scannability has suffered. This proposal asks more from callers in terms variable length/descriptiveness (stuff we write) in order to trim API verbosity: stuff xcode and or auto completes writes for us.

If we are going to apply some linguistic tools to support interop, might as well be consistent about parameter requirement rules. Maybe there are too many edge cases for this naming?
string.writeTo(URL: filePath, atomically: ...) //string.write(URL: <#url#>, automically:..) from auto complete

# ? Jan 31, 2016 17:00

lord funk: Feb 16, 2004

Kallikrates posted:

If we are going to apply some linguistic tools to support interop, might as well be consistent about parameter requirement rules. Maybe there are too many edge cases for this naming?
string.writeTo(URL: filePath, atomically: ...) //string.write(URL: <#url#>, automically:..) from auto complete

I'm 100% for requiring external parameter names all of the time, if the alternative is the new brevity model.

# ? Jan 31, 2016 17:15

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 23:33

nah thanks: Jun 18, 2004; Take me out.

Kallikrates posted:

I also think the point examples are a little too simplistic as lord funk shows. We're told to remove as much redundant type info and rely on inference as much as possible.
string.writeTo(filePath, atomically: ...)
Scanning that code 6 moths from now I am definitely not going to remember if filePath was a URI or String. If I have to fall back to hungarian notation-ish I think readability/scannability has suffered. This proposal asks more from callers in terms variable length/descriptiveness (stuff we write) in order to trim API verbosity: stuff xcode and or auto completes writes for us.

Right - this change just trades one kind of verbosity for another. Instead of writeToURL(filePath), I'll have code that looks like writeTo(filePathString) or writeTo(filePathURL) or whatever. Then, because this naming pattern is totally optional, I'll inevitably forget to use it at some point and write stuff that's confusing to re-read later.

The existing verbose method names save me from myself, and make unfamiliar APIs and codebases easier to navigate, even if they can be annoying at times.

nah thanks fucked around with this message at 17:32 on Jan 31, 2016

# ? Jan 31, 2016 17:26

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Just one more thing - Swift thread

«‹›48 »