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

«‹›10 »

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

Siguy posted:

I'm curious about this distinction. Why not let function calls also include parameter names?

There are a couple different things in play here.

First, there's value in all calls to the same entity looking consistent, as opposed to some using argument names and others not. A scripting language probably wouldn't care, but we do. That's probably not in flux.

Second, there was a sense among some of us that native Swift declarations shouldn't feel completely different from imported C/ObjC declarations. ObjC methods have argument names, but C functions do not. I don't think I agree with this position, but it's where we are right now. This probably is in flux.

You still can provide argument names for free functions (in which case they'll become required); they're just not the default.

# ¿ Jun 3, 2014 09:19

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 22:45

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

Filburt Shellbach posted:

Haven't finished reading the book yet... is there a way to inspect the type of a variable or constant in the playground? like ghc's :t

I'm not totally up on playgrounds, but IIRC, you can option-click on random things.

# ¿ Jun 3, 2014 16:35

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

lord funk posted:

Question for rjmccall: will there be a Swift version of sets?

Almost certainly.

# ¿ Jun 3, 2014 16:36

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

EngineerJoe posted:

Super interesting thread. It's neat to see the thought that goes into designing a language that will be as important as Swift. My question is will we be able to get the string representation of enums?

Yes, it's something we want to make easy to do.

# ¿ Jun 3, 2014 16:43

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

Malcolm XML posted:

Also can you add a deriving mechanism like Haskell so I don't have to reimplement stuff like equality and string representation + json serialization?

We want to, yes.

# ¿ Jun 3, 2014 20:13

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

lord funk posted:

Yeah me too.

Filed.

# ¿ Jun 4, 2014 00:20

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

LP0 ON FIRE posted:

I was just reading about this. If I'm understanding correctly, it can be any sequence of the following 14 characters: / = - + * % < > ! & | ^ . ~
https://developer.apple.com/library...097-CH27-XID_48

. is restricted. You can also use non-ASCII characters; we haven't decide exactly which set, but it'll include the math symbols for sure.

lord funk posted:

If Swift is a recent name, what did you guys call the language internally while you were developing it?

I don't know why, but we never disclose stuff like that. It's not unlikely that somebody will slip up and say it at some point, though.

# ¿ Jun 4, 2014 02:05

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

Dessert Rose posted:

Having some problems with interop. The docs seem to suggest that I should import "ModuleName-Swift.h" into all the ObjC files that need to have access to Swift classes.

My module name is for sure AdultQuest because Xcode generated "AdultQuest-Bridging-Header.h" for the other side. I don't see AdultQuest-Swift.h in my project anywhere, though, and when I try to import it, I get an error complaining that it's unable to find it.

It sounds like Xcode decided to name your bridging header "AdultQuest-Bridging-Header.h" for some reason. The file name isn't magical, and I assume there's a build setting for it somewhere. Basically, Swift "includes" it to find local definitions from your project that it should make visible to Swift files.

Not sure what's going on with your protocol. I know there's an occasional issue where we import protocols as FooProto instead of Foo, but IIRC that should only happen when there's an actual name conflict with an ObjC protocol (which live in a different namespace in ObjC).

# ¿ Jun 4, 2014 07:04

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

Yes. That one is definitely on the list.

As a workaround, you can probably afford to add AnyObject to the protocol constraints on your type parameter.

# ¿ Jun 4, 2014 07:25

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

spongeh posted:

Is there any chance at being able to use this for cross-platform dev in the future? If it outputs LLVM, and integrates with C libraries, it should be feasible once it hits open source, right? Or is too much useful stuff tied up in Cocoa that you'd lose most of the nice bits if you were trying to build on Linux or Windows.

There's a significant amount of code dedicated to Cocoa-specific interop, but non-Darwin platforms should just never trigger it by virtue of not having ObjC/CF code. I expect that a port would need to duplicate a pretty simple subset of the ObjC runtime (just for class-layout resilience) and then be done.

Obviously, if you want a Windows port to e.g. import COM types as Swift classes, that is (1) implementable but (2) significantly more work.

# ¿ Jun 4, 2014 09:27

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

Did they really not sandbox the playground? Ugh. Well, this is why it's a beta.

# ¿ Jun 4, 2014 22:10

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

tstm posted:

The optimizer seems to do some really weird things for me.

This is all really awesome, and I filed it (rdar://17160101) for us to look into and consider as a benchmark.

# ¿ Jun 4, 2014 22:17

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

Filburt Shellbach posted:

rjmccall: Would you like me to continue? Or has your team already evaluated and rejected traits as a feature for Swift? Or are protocols that much beefier than Objective-C's that I've already got what I want? If this is new to you I'm more than happy to start filing radars loaded with citations both for their theoretical and practical value!

I think that what you're doing in your wall o' text can be reasonably modeled with just default implementations in protocols, which is something we want to do.

# ¿ Jun 5, 2014 00:42

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

It should work; it's worth a bug.

# ¿ Jun 5, 2014 01:41

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

Axiem posted:

rjmccall, what do you make of this article on benchmarking Swift vs. Obj-C?

Our optimizer isn't where we want it to be yet; there are abstractions being inserted by the standard library that we aren't good enough at removing.

Also, integer arithmetic not matching C performance is not surprising, because we do overflow checking.

But the fact that the post started off by comparing unoptimized builds, and even now is comparing Swift (which uses ARC) against what seems to be manual refcounting, is not inspiring.

# ¿ Jun 5, 2014 16:22

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

Dessert Rose posted:

But I can't appear to cast the return value from insertNewObjectForEntityForName to this class. I assigned it to AnyObject and the type isn't quite the same name.

I can work around it for now by just creating the object outside of the class, but I kind of like being able to construct a Core Data object by just passing some parameters and the context.

Should I file a radar?

Yes, please do. This is probably a matter of us getting somehow confused by the dynamic subclassing that Core Data does.

# ¿ Jun 5, 2014 16:25

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

Scaevolus posted:

What happens when you cause an overflow with normal arithmetic, though? It specifies that it's trapped and reported as an error, but is there any way for a user to handle that?

By design, no. We want to eventually provide a high-level last-resort recovery mechanism, but we don't want a model where programmers can retroactively catch and recover from individual programming-error faults like this. Among other things, it precludes having a "disable the checks" compilation mode, because that would change semantics.

# ¿ Jun 5, 2014 16:31

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

Axiem posted:

Oh, and I think I heard an Apple Engineer today slip up and use the code name for Swift instead of Swift. Those in Apple: any idea if it is actually a Firefly reference? (Or is it just as likely to have been the wrong word, but not the codename)

It is a Firefly reference.

Also I feel very slightly bad for randomly making fun of Ada. Only very slightly, though.

# ¿ Jun 6, 2014 06:46

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

Hughlander posted:

Any access to some of the lower level obj c runtime? Like associated objects ?

We have plans in this area.

# ¿ Jun 6, 2014 18:49

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

toiletbrush posted:

Is Swift going to enable better refactoring support in Xcode? I really, really miss Resharper when doing ObjC dev

Swift should certainly make it easier to do good tooling like this. I shouldn't speculate about specific future work, though.

toiletbrush posted:

Also, I'm writing an iPhone app that makes a lot of use of raw C byte arrays for performance, is there a performant way to allocate and read/write a raw c-style array with Swift, or should I leave that bit in ObjC?

UnsafePointer has alloc and dealloc operations.

# ¿ Jun 6, 2014 22:03

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

Meat Street posted:

rjmccall: I saw that Chris retweeted someone talking about the -Otime flag to disable runtime safety checks. I have to assume this wasn't a general endorsement of using that flag, right? Am I missing something here? Unless your code is basically a series of proofs a la Haskell, I don't know why you'd want to opt out of that.

Plorkeyran said basically everything I would have, so I'll just note for the record that it's -Ofast.

# ¿ Jun 7, 2014 04:02

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

Dessert Rose posted:

Okay, but this has the same result:

code:


enum Foo
{
    case Bar(Int)
}

var baz = Foo.Bar(42)
switch (baz)
{
case var .Bar(val):
    val -= 1
}
switch (baz)
{
case var .Bar(val):
    val -= 1
}

val is just a copy of the value stored there; there is no way to update in-place like this, and that's by design.

# ¿ Jun 8, 2014 20:06

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

Ender.uNF posted:

error: Use of unresolved identifier 'doIt'

So the compiler isn't smart enough to resolve symbols declared in the same file unless declared in-order?

There are secretly two kinds of swift file: scripts and everything else. Scripts are evaluated line-by-line, which (for various reasons) means that it's not reasonable for lookup to find things declared later. In a non-script, you can't have expressions at the top-level, global variables are initialized lazily, and everything is allowed to refer to everything. Playgrounds and the REPL are processed as scripts.

# ¿ Jun 8, 2014 20:11

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

Ender.uNF posted:

Here, have some exception handling in Swift:

This is really cool.

Meat Street posted:

It was a design decision of the language to not have exceptions and I doubt they'll double back on that

I wouldn't go that far. I'd say that we aren't very happy with the EH designs of current languages and want some more time to evaluate our options without committing to something half-assed.

# ¿ Jun 8, 2014 20:17

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

shodanjr_gr posted:

Also, does Swift allow C-style typedefs? Those try function signatures look like brainfuck at first glance.

That's what typealias is. (Except in a protocol body.)

# ¿ Jun 8, 2014 20:18

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

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.

That's not to say that we couldn't do something like that as sugar, though.

# ¿ Jun 8, 2014 21:59

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

It was crazier during the actual talk, because I actually sprinted through the remaining half-dozen slides, rushing all the content while the staff turned on the music and raised the house lights. We debated what to do for the recording, and I told them to cut there because (1) it is hilariously abrupt and (2) the next fifteen seconds were basically just me stuttering out gibberish anyway while I slowly realized what was happening.

Meat Street, I don't have specific suggestions about learning functional programming, sorry.

# ¿ Jun 9, 2014 06:32

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

Hughlander posted:

Who's the evangelist? I want to send in E-Mail asking that you go back and loop over the slides / remaining slides and give the full presentation as it was designed to be.

The DT evangelist is Dave DeLong. There really isn't much substantive missing content, though:

1. Overflow checking is good.
2. There are masking operators which skip overflow checks when you want that, like if you're writing a hash function.
3. You can pass -Ofast to turn off safety checks file-by-file when you're certain that's a good idea.
4. Let's recap what we talked about today.
5. Thanks for coming and have a great WWDC.

# ¿ Jun 9, 2014 17:45

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

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: Sep 7, 2007; no worries friend; Fun Shoe

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: Sep 7, 2007; no worries friend; Fun Shoe

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

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

Ender.uNF posted:

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.

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:

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.)

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.
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

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

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

lord funk posted:

The required type casting is feeling brutal. For a function that takes a CGFloat:
code:
CGFloat(fmaxf(CFloat(CGFloat(offset) / view.bounds.width), 0.0))
Old style
code:
fmaxf(offset / view.bounds.width, 0.0)
Any technique to mitigate this that I'm missing? Or am I just whining.

Assuming that offset isn't a CGFloat for some reason:

code:

max(CGFloat(offset) / view.bounds.width, 0)

Bonus: doesn't randomly do unnecessary double->float->double conversions on 64-bit platforms.

# ¿ Jun 11, 2014 22:29

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

ultramiraculous posted:

Any idea why this is an issue?
code:
let seq: Sequence = ["1"]
seq.generate() //Error: 'Sequence' does not have a member named 'Generate'
I'm trying to do some generic collection extensions and this is causing me some trouble.

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

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

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

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

Gul Banana posted:

is there a moral equivalent, in Swift, of this C# code?
code:
        void IncrementAll(IEnumerable<T> ts) {
            foreach (var t in ts) {
                t.x++;
            }
        }

        var collection1 = new List<T>();
        var collection2 = new HashSet<T>();
        var collection3 = new T[]{};

        //add data to the collections

        IncrementAll(collection1);
        IncrementAll(collection2);
        IncrementAll(collection3);
e.g. can i use multiple generic types which implement the same protocol, and then pass them into a function, preserving the type info necessary for that protocol to work?

As long as you're just calling the function, there's absolutely no reason for it to not be generic, i.e.:

Swift code:

  func incrementAll<S: Sequence where S.GeneratorType.Element==T>(s: S) {
    for t in s {
      t.x++;
    }
  }

If you need to store values of the sequence, that's what SequenceOf<T> is for, as long as you don't need to recover the original sequence value/type. There is currently no way to externally constrain the associated types of a protocol type, which is a known and unfortunate deficiency.

# ¿ Jun 12, 2014 09:18

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

More specifically, the compiler can't prove that the loop will definitely assign to largeKind. It turns out that it does because there's at least one entry in interestingNumbers whose value contains at least one positive number (and in fact, all the entries contain only positive numbers), but you can't really expect the compiler to prove all that for you just to know that it's safe to use largeKind. So it conservatively expects you to assign it yourself.

I would advise a more advanced programmer to use String! here to encode the assumption that the variable will be assigned before use. For a novice, though, I think it's better to stick with String? so that you can see what's going on more explicitly.

# ¿ Jun 14, 2014 21:04

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

Choadmaster posted:

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:

Right, this is definitely something we want to do.

# ¿ Jun 14, 2014 21:05

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

Choadmaster posted:

I take it there's not any way to reset/invalidate a lazy property, is there?

No. You can file a bug, though. I suspect we'll say it's not worth complicating the feature over, though, since I actually cannot think of any natural way of resetting it like that.

# ¿ Jun 15, 2014 10:08

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 22:45

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

dizzywhip posted:

What's the best way to iterate over all of the values in an enum? Ideally I'd like to be able to do something like for value in MyEnum { ... }. Is there anything like that in Swift, or is it at least something that's planned for the future?

Vaguely planned. I'll add this to the OP, it keeps coming up.

# ¿ Jun 18, 2014 05:53

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

«‹›10 »