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

«‹›2 »

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

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 16:30

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

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

Joining the bandwagon of people who have taught programming and prefer the extra verbosity of Swift's inherited APIs. I think there is a lot about Swift that would make it a great first teaching language, and the prose-like APIs are part of that. Sure, there are inconsistencies (the first argument name being attached to method name and not the argument list, and the way that affects how the first argument is declared vs all the other arguments), but those can be fixed. Getting rid of unnecessary prefixes is great, but we shouldn't go down the path of making the language look like Perl or Python in its terseness.

# ¿ Feb 1, 2016 18:08

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

Is there an upper limit to the number of arguments in a closure, or does this mean I can write $8008135 if I'm patient enough?

# ¿ Feb 17, 2016 20:57

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:

There's certainly some implementation limit, and it's probably lower than we strictly validate, but there's no particular reason for us to impose a language limit.

Well, I gave let x = { $8008135 } five minutes to compile before I gave up and killed it. I imagine eventually it would either hit the "unable to infer closure return type" error that I would expect, or die for some other resource exhaustion reason.

I'm tempted to file a bug, but this is really stupid :v:

Edit: Because I'm procrastinating, I did a little digging. It looks like referencing $n in a closure is quadratic on n (albeit with a low constant). Extrapolating the results of $0 through $3500 or so...

$8008135 would take about 275 days to compile.

Flobbster fucked around with this message at 04:04 on Feb 18, 2016

# ¿ Feb 18, 2016 02:03

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:

Out of curiosity, is it still non-linear if you only parse / type-check? There are command-line options you can use for this.

swiftc -parse -dump-type-refinement-contexts for $3500 still takes about 3.5 seconds to complete before erroring out, so it looks like yes.

I should mention that I'm using Swift 2.1 for this�I don't have 2.2 installed on this machine, but I know there were a ton of codegen/performance improvements in that release. Not sure if this is something that would be affected, though.

# ¿ Feb 18, 2016 04:46

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

Does this mean you're also looking at ways make it easier to write fluent interfaces/builders with structs? Right now having the initializer result be immutable is a showstopper because I can't write "let foo = Foo().something(5).somethingElse(10)" even if those methods are mutating.

I've been working on a side project where I've had an opportunity to really use protocol-oriented programming, extensions, constraints, and generics in some cool ways and I've gotta say, I love just how algebraically Swift lets me design components. Being able to say "this type implements this set of methods, but also this superset of additional methods if the associated type is X" is mind blowing. And I've only written one class, and it was purely an implementation detail to get copy-on-write for a value type.

# ¿ Feb 26, 2016 00:24

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

Yeah, there's still a TON of stuff in the Generics Manifesto that needs to get done and would certainly have big impacts on the ABI. I'm glad they're not rushing it.

# ¿ May 16, 2016 22:21

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

HaB posted:

this fixed it.

Thanks.

That's odd�in my experience, setting the visibility of the member should have been enough. Visibility and extensions seems to be an odd spot in the language.

Don't force-unwrap your optionals though. Do this instead:

code:

        if let first = self.characters.first {
          self = String(self.characters.dropFirst(1))
          self.append(first)
        }
        return self

Now you can also rotate the empty string without it crashing!

# ¿ Jun 11, 2016 22:23

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

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

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: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

The apoplexy around open-by-default classes is bad, but I'm now more concerned by the number of people who vehemently and loudly fail to understand that, yes, the empty string is a prefix and suffix of every other string. This is easily demonstrable with basic axioms.

Am I wrong to expect that people writing software should have the most basic understanding of formal language theory? (Or at least, when multiple people explain in basic terms why it's the case, you don't double down on your wrong ideas?)

Flobbster fucked around with this message at 23:36 on Jul 21, 2016

# ¿ Jul 21, 2016 23:30

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

lord funk posted:

Well, kind of, yeah. A lot of us come from other disciplines and learn as we go.

That's fair. It's the former academic coming out in me, I guess.

If the guy graduated from a 4-year CS program though, I can't excuse that.

# ¿ Jul 21, 2016 23:56

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

On today's trashy episode of Housewives of Swift Evolution... "I don't care what the evolution process decided! Removing C-style for loops was a bad idea and I'm going to beg them right at the deadline to leave them in and I'll write a post-Swift 3 proposal to put them back! Fixing my code is too hard, so I'll demand the language conform to me instead! YOU'LL ALL SEE!"

:allears:

# ¿ Jul 28, 2016 23:23

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

A lot of posts on swift-evolution are terrible ideas. They're trying to have the language hold their hand when they can't type a method signature correctly. I for one don't want to have to type more keywords everywhere because of that.

The complaints about "if I have a default implementation and try to override it but use the wrong signature" are slightly more reasonable, but are they not unit testing their code? That's like one of the most obvious things you should write a test for.

Then you have the crazies going "String should be able to implement Collection three different ways at once!" :bang:

# ¿ Sep 21, 2016 14:14

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

sarehu posted:

Avoiding mistakes and avoiding the need to implement stupid unit tests sounds like a great idea to me.

There's an inflection point where it no longer becomes worth it. I don't have any desire to have keyword soup on every line of Swift because people think everything needs to be explicit or else the code base is "fragile."

Plus, they wouldn't be writing a new unit test for "did this method override this default protocol implementation". The unit tests they should already be writing in the first place for the type should catch "this method had the wrong behavior" if they incorrectly spelled a method in the implementation and it ended up not replacing the default.

I'm sure there's a better solution to this problem than the current state of things, but many of the solutions being offered on the mailing list are myopic and not well thought out. (I'm fond of the idea that extensions that declare protocol conformance should only be allowed to define things in that satisfy that conformance, and possibly lower-visibility helpers used therein, but that's currently hampered by the fact that extensions can't have stored properties yet.)

# ¿ Sep 21, 2016 22:29

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

Doctor w-rw-rw- posted:

Trying Swift again. Swift won't let me "let x: Foo<Any> = something", where something is Foo<Bar>. Trying to wrap my head around a non-type-erased system. Am I doing something wrong here?

Generics aren't covariant in Swift. Imagine that Foo<T> is a type that has a writable property of type T or a method with an argument of type T. The statement you're trying to write would assign a Foo<Bar> to a variable that would let you set a property or call a method with an Any when it's expecting a Bar.

# ¿ Oct 3, 2016 07:34

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

I wish I had a nickel for every thread full of bad ideas about access control on swift-evolution right now.

The obvious right thing to do is admit that SE-0025 was a bad idea and roll it back. Nobody needs scoped access vs. file-private access�you're only protecting yourself from yourself. It's a pointless distinction and if you need it, your files are too drat big.

File-private could also be argued to be protecting oneself from oneself compared to internal, but as someone who works on a project that involves codegen, without control over which module a user adds those files to, file-private is very nice to hide details.

I'm not wading into these conversations though until they die down a bit. Get jobs, people!

# ¿ Feb 21, 2017 17:56

Adbot: ADBOT LOVES YOU

# ¿ May 14, 2024 16:30

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

Toady posted:

Wouldn't this break?

code:


class ContrivedExample {
    private func foo() {}
}

extension ContrivedExample {
    private func foo() {}
}

If somebody does something that dumb, they deserve to be broken :v:

# ¿ Feb 21, 2017 19:44

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

«‹›2 »