Incoherent thoughts.
I really wish Swift would figure out how to handle let-constants with multiple designated initializers, as in UIViewController. As it stands, you cannot let a let member depend on another initializer because every designated initializer must set all stored properties for non-default value items. That means you can’t share code and there’s no OneInitToRuleThemAll/OneTrueInitilializer exception built in to reduce redundant set-up.
Would be nice to have a @justdoitalready init() that knows how to convenience and defer to the designated items without having to load a nib or invoke a coder.
When you conform to a new protocol, you get this. It’s about as helpful as a ladder on roller skates.
The actual answer is this:
Theoretically, you also need a typealias for Element and Index but the Swift compiler can infer those. It would be really lovely if someone *kofnatecookkof* could cook up a list of minimal protocol conformances. But then again, it would also be great to have a per-type and per-protocol list of conformance vocabulary that’s easier to search through and read than my current mess.
Annoyance of the day. Cannot use double quotes within Swift expression string interpolation (not just \”, I know about \”) because I cannot find any way to escape. Got a solution, let me know.
func f(x: String) -> String {return "{\(x)}"} let foo = "\(f("hello"))" // how do you escape those internal "'s? // "\(f(\\\"hello\\\"))" // not like this
Bonus baby geep video.
3 Comments
IMO escaping this string is not possible. The method needs string parameter and the method is injected into string for interpolation. I think the only option is to move parameter out of a string and change it to let and pass this let to the f method or just make the string simpler 🙂 Thinking about any example when what you’re trying to achieve would be better than keeping some variables out of the string and injecting them or better than just some string concatenation, and cannot find any 🙂
Any special reason in mind why to force ugly nested escapes?
Why not simply writing let bar = “” + f(“hallo”) + “”?
I’m pretty sure such a cascade of nested escapes would open up a hell of inevitable security bugs.
For code sharing in initializers you could use tuples and do something like that: