3

さて、Swiftでオプションを使用する通常の方法は、オプションのバインディングを介してそれらをアンラップすることです...

let stringA:String? = nil // (or "ABC")

if let unwrappedStringA = stringA
{
    let x:String = unwrappedStringA
}

しかし、暗黙的にアンラップされたオプションを使用する次の方法も見ました。これは、追加の変数を必要としないだけでなく、「読み」やすく、英語に似ているため、個人的にはきれいに見えると思います (つまり、「これがnil ではありません...') そして可読性は Swift の核となる信条の 1 つです (特に今後の Swift 3.0 では)。

let stringA:String! = nil // (or "ABC")

if stringA != nil
{
    let x:String = stringA
}

ただし、後者に関しては、Swift の「純粋主義者」はこれを「コードの匂い」と呼び、「悪い、悪い、悪い!!」と主張します...しかし、彼らは理由を説明しません! では、なぜそんなに悪いのですか？

注: はい、暗黙的にラップ解除されたオプションでは使用できない Optional チェーンやその他の機能については知っています。それらはすべて非常に優れた機能ですが、暗黙的にラップ解除されたオプションを nil に対してテストすることの技術的な欠点について具体的に尋ねています。対オプションのバインディング。

私が期待しているのは、一方が他方よりも優れている定量化可能な技術的な理由です (つまり、コンパイラの最適化、より優れた安全性チェック、パフォーマンスなど)。それをするために！' それが理にかなっていることを願っています。

アップデート

私は実際に、ラップされていない変数を保持するために新しい変数を作成する必要があるという私の懸念の 1 つ (少なくとも表面的な方法で) に対処する方法を見つけました。ここでの秘訣は、ラップされていない変数は実際にはオプション自体とは異なるスコープにあるため、まったく同じ名前を使用できることです。

さらに、大括弧自体の内側には、stringA という名前の変数を持つことができるさらに別のスコープがあります。これは、3 つの 'stringA' 変数を使用できるようになったことを意味します (しかし、そうすべきというわけではありません! )...

  1. オプションの
  2. アンラップされたオプション
  3. 括弧内の新しいローカル変数

これを示すこのクレイジーなコードは次のとおりです...

let stringA:String? = nil // (or "ABC") // First stringA variable

if let stringA = stringA
{
    let x:String = stringA // <- This stringA is the unwrapped optional (the second stringA)

    // Now we're just getting crazy (and smelly!)
    let stringA = stringA + stringA // <- This is yet another stringA (third one!)
    let y:String = stringA 
}

繰り返しますが、私はこれを容認しません!! 他の人が有益な観点から興味深いと思うコードをいくつか示しているだけです。確かにやった！

4

3 に答える 3

3

IUO の本当の目的を明確にしましょう。それらは、Objective-C との通信用のデバイスとして純粋に生まれました。理論的には、Objective-C からのオブジェクトはすべてである可能性があるため、当初、Objective-C からのすべてのオブジェクトは Optional でした。そのようなすべての Optional を真の Optional にすることは混乱を招きすぎたため、そのようなすべてのオブジェクトは暗黙的にアンラップされた Optional でした。nil

しかしその後、Apple は API を手動で微調整して、Objective-C からのオブジェクトが実際にnil. その手作業による微調整プロセスは、ほぼ完了しました (Swift 3)。したがって、Objective-C から来るものはすべて、通常のオブジェクトまたは通常の Optional (場合によっては、try取得するために a を介して渡さなければならない通常のオブジェクト) のいずれかになります。

そのため、暗黙的にアンラップされた Optionalは実際にはまったく必要ありません。現時点では、これらはプログラマーにとって怠惰な利便性に他なりません。そして、他の言語装置が登場して、それらを不要にしています。たとえば、Optional を with でアンラップしif let、レベルの中括弧を追加しなければならないのは面倒ですが、今では、レベルの中括弧を追加せずguard letにアンラップできるようになりました。

そのため、Apple はネジを締め始め、IUO の利便性を低下させています。たとえば、vacawama が正しく言ったように、それらは代入によって伝播されなくなりました。また、IUO の配列のようなものはなくなりました (たとえば、[Int!]型ではなくなりました)。

このプロセスは、IUO が合法である状況がほとんどなくなるまで続けられます。したがって、今すぐそれらを使用する習慣をやめることが最善です。

于 2016-07-13T03:12:23.667 に答える