.isEmpty ?? true {…}
> if myBool ?? false {…}
> if (myInt ?? 0) > otherInt {…}
>
> This is only slightly more code, but it removes all your assumptions, and
> means you are now the specifier in your code’s logic. You can see from the
> code exactly what nil will do, and w
ould be. Sometimes it will be false, other times it will
> be true. So far better to explicitly show what the default is.
>
>
>> On 11 May 2016, at 10:16 PM, Basem Emara via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> Forcing unwrappin
Hi Daniele, to me at first glance, it looks like a shorthand for creating
multiple variables. I would expect to try something like this later:
“print(name); print(surname)”, which of course wouldn’t be the intent.
Basem
> On May 7, 2016, at 3:42 PM, Daniele Riccardelli via swift-evolution
>
Yes I digress and agree with you consistency is absolute key. Another thought
came to mind:
Option 3 3: Uppercase all acronyms including those with mixed casing. This is
both consistent and clear. Isolating acronyms is important because they loose
their meaning and bleed into word boundaries,
How about mutating keyword just like func's:
mutating protocol Foo {…}
Isn’t that what the current “class” keyword is trying to indicate? It feels
awkward that a protocol would inherit from a reference type when just looking
at the syntax, whether it be class, AnyObject, etc.
> On May 5,
I’ve been trying to keep up with this thread and this crossed my mind too. Of
course, we don’t want to rule out multi-line strings because of readability and
flexibility (Python “”” or Markdown’s ```…``` would be my vote). However, a
built-in tempting engine like Mustache would be progressive
Hey Hooman, that’s very elegant. I didn’t think of it like that and will
definitely use, thx!
Though wouldn’t “defer init()” take it a step further: 1) reduce redundant
boilerplate 2) prevent forgetting/bugs and 3) smaller memory allocation
footprint? It also fits well with the existing Swift
in init we can set un-initialized stored properties.
>
> But, why implicitly unwrapped optionals are not solution here? I.e.
>
> private var videoPlayer: AVPlayer!
> private var videoPlayerLayer: AVPlayerLayer!
>
>
>> On 28.04.2016 19:04, Basem Emara via swift-evolution w
I see what you’re saying and the forced optionals is pretty inconvenient.
As far as syntax, how about more of a “deferred” init that gets triggered
regardless like this:
defer init() {
// Always gets called no matter what designated init triggers
}
> On Apr 27, 2016, at 5:52 PM, Shannon
