名前はセキュリティを保証するものではありません。Haskellと型安全性

Haskellの開発者は型安全性について多くのことを話します。 Haskell開発コミュニティは、「型システムのレベルで不変条件を記述する」および「無効な状態を除外する」というアイデアを提唱しています。刺激的な目標のように聞こえます！しかし、それを達成する方法は完全には明確ではありません。ほぼ1年前、私は「解析、検証しない」という記事を公開しました 。これは、このギャップを埋めるための最初のステップです。



この記事の後には生産的な議論が続きましたが、Haskellでのnewtype構造の正しい使用についてコンセンサスを得ることができませんでした。考え方は非常に単純です。newtypeキーワードは、名前は異なりますが、代表的にはラップするタイプと同等のラッパータイプを宣言します。一見すると、これは型安全性を達成するための理解できる方法です。たとえば、newtype宣言を使用して電子メールアドレスのタイプを定義する方法を検討してください。

newtype EmailAddress = EmailAddress Text
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

このトリックは私たちに何らかの意味を与え、スマートコンストラクターとカプセル化境界と組み合わせると、セキュリティを提供することさえできます。しかし、これはまったく異なる種類の安全性です。それははるかに弱く、1年前に私が特定したものとは異なります。それ自体、newtypeは単なるエイリアスです。



名前は型安全性ではありません©

内部および外部のセキュリティ

建設的なデータモデリング（前の記事で詳しく説明します）とnewtypeラッパーの違いを示す ために、例を見てみましょう。「1から5までの整数」という型が必要だとします。建設的モデリングへの自然なアプローチは、5つのケースでの列挙です。

data OneToFive
  = One
  | Two
  | Three
  | Four
  | Five
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

次に、IntとOneToFiveタイプの間で変換するいくつかの関数を記述します。

toOneToFive :: Int -> Maybe OneToFive
toOneToFive 1 = Just One
toOneToFive 2 = Just Two
toOneToFive 3 = Just Three
toOneToFive 4 = Just Four
toOneToFive 5 = Just Five
toOneToFive _ = Nothing

fromOneToFive :: OneToFive -> Int
fromOneToFive One   = 1
fromOneToFive Two   = 2
fromOneToFive Three = 3
fromOneToFive Four  = 4
fromOneToFive Five  = 5
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

これは、述べられた目標を達成するのに十分ですが、実際には、そのようなテクノロジーを使用することは不便です。まったく新しいタイプを発明したので、Haskellが提供する通常の数値関数を再利用することはできません。したがって、多くの開発者は代わりにnewtypeラッパーを使用することを好みます。

newtype OneToFive = OneToFive Int
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

最初のケースと同様に、関数toOneToFiveとfromOneToFiveを同じタイプで宣言できます。

toOneToFive :: Int -> Maybe OneToFive
toOneToFive n
  | n >= 1 && n <= 5 = Just $ OneToFive n
  | otherwise        = Nothing

fromOneToFive :: OneToFive -> Int
fromOneToFive (OneToFive n) = n
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

これらの宣言を別のモジュールに配置し、OneToFiveコンストラクターをエクスポートしないことを選択した場合、APIは完全に交換可能です。newtypeオプションはより単純で、よりタイプセーフなようです。ただし、これは完全に真実ではありません。



OneToFive値を引数として取る関数を作成していると想像してみましょう。建設的モデリングでは、このような関数には5つのコンストラクターのそれぞれとのパターンマッチングが必要です。GHCは、次の定義を十分に受け入れます。

ordinal :: OneToFive -> Text
ordinal One   = "first"
ordinal Two   = "second"
ordinal Three = "third"
ordinal Four  = "fourth"
ordinal Five  = "fifth"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ニュータイプの表示が異なります。Newtypeは不透明なので、それを観察する唯一の方法はIntに戻すことです。もちろん、Intには1〜5以外の多くの値を含めることができるため、残りの可能な値のパターンを追加する必要があります。

ordinal :: OneToFive -> Text
ordinal n = case fromOneToFive n of
  1 -> "first"
  2 -> "second"
  3 -> "third"
  4 -> "fourth"
  5 -> "fifth"
  _ -> error "impossible: bad OneToFive value"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この架空の例では、問題が発生しない可能性があります。しかし、それにもかかわらず、説明されている2つのアプローチによって提供される保証の重要な違いを示しています。

• 建設的なデータ型は、さらなる相互作用に利用できるように不変条件を修正します。これにより、序数関数は表現できなくなったため、無効な値を処理できなくなります。
• newtypeラッパーは、値を検証するスマートコンストラクターを提供しますが、この検証のブール結果は、制御フローにのみ使用されます。関数の結果として保存されません。したがって、このチェックの結果と導入された制限をこれ以上使用することはできません。その後の実行中に、Int型と対話します。

完全性をチェックすることは不必要なステップのように思えるかもしれませんが、そうではありません。バグを悪用することで、型システムの脆弱性が指摘されています。 OneToFiveデータ型に別のコンストラクターを追加する場合、建設的なデータ型を使用する序数のバージョンは、コンパイル時にすぐに網羅的ではなくなります。その間、newtypeラッパーを使用する別のバージョンはコンパイルを続けますが、実行時に中断し、不可能なシナリオになります。



これはすべて、建設的モデリングが本質的に型安全であるという事実の結果です。つまり、セキュリティプロパティは型宣言によって提供されます。無効な値を表すことは実際には不可能です：5つのコンストラクターのいずれかを使用して6を表示することはできません。



これは、intと本質的な意味上の違いがないため、newtype宣言には適用されません。その値は、巧妙なtoOneToFiveコンストラクターを介して外部から指定されます。newtypeによって暗示されるセマンティックの違いは、型システムからは見えません。開発者はこれを念頭に置いています。

空でないリストの再検討

OneToFiveデータ型が発明されましたが、他のより現実的なシナリオにも同様の考慮事項が適用されます。以前に書いたNonEmptyについて考えてみましょう。

data NonEmpty a = a :| [a]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

明確にするために、通常のリストと比較して、knewtypeを介して宣言されたNonEmptyのバージョンを想像してみましょう。通常のスマートコンストラクター戦略を使用して、目的の空でないプロパティを提供できます。

newtype NonEmpty a = NonEmpty [a]

nonEmpty :: [a] -> Maybe (NonEmpty a)
nonEmpty [] = Nothing
nonEmpty xs = Just $ NonEmpty xs

instance Foldable NonEmpty where
  toList (NonEmpty xs) = xs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

OneToFiveと同様に、この情報を型システムに格納できない場合の結果をすぐに発見できます。NonEmptyを使用して安全なバージョンのheadを作成したかったのですが、newtypeバージョンには別のステートメントが必要です。

head :: NonEmpty a -> a
head xs = case toList xs of
  x:_ -> x
  []  -> error "impossible: empty NonEmpty value"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

それは問題ではないようです。そのような状況が発生する可能性は非常に低いです。しかし、そのような議論は、NonEmptyを定義するモジュールの正しさを信じることに完全に依存していますが、建設的な定義では、GHC型チェックを信頼するだけで済みます。デフォルトでは型チェックが正しく機能すると想定しているため、後者の方が説得力のある証拠です。

トークンとしてのニュータイプ

あなたがニュータイプを愛しているなら、このトピックはイライラするかもしれません。ニュータイプがコメントよりも優れているという意味ではありませんが、コメントはタイプチェックに効果的です。幸いなことに、状況はそれほど悪くはありません。ニュータイプはセキュリティを弱める可能性があります。



抽象化の境界は、ニュータイプに大きなセキュリティ上の利点をもたらします。 newtypeコンストラクターがエクスポートされない場合、他のモジュールに対して不透明になります。ニュータイプを定義するモジュール（つまり、「ホームモジュール」）は、これを利用して、クライアントを安全なAPIに制限することにより、内部不変条件が適用される信頼境界を作成できます。



上記のNonEmptyの例を使用して、このテクノロジーを説明できます。今のところ、NonEmptyコンストラクターのエクスポートは控えて、ヘッド操作とテール操作を提供しましょう。私たちは彼らが適切に働いていると信じています：

module Data.List.NonEmpty.Newtype
  ( NonEmpty
  , cons
  , nonEmpty
  , head
  , tail
  ) where

newtype NonEmpty a = NonEmpty [a]

cons :: a -> [a] -> NonEmpty a
cons x xs = NonEmpty (x:xs)

nonEmpty :: [a] -> Maybe (NonEmpty a)
nonEmpty [] = Nothing
nonEmpty xs = Just $ NonEmpty xs

head :: NonEmpty a -> a
head (NonEmpty (x:_)) = x
head (NonEmpty [])    = error "impossible: empty NonEmpty value"

tail :: NonEmpty a -> [a]
tail (NonEmpty (_:xs)) = xs
tail (NonEmpty [])     = error "impossible: empty NonEmpty value"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

NonEmpty値を作成または使用する唯一の方法は、エクスポートされたData.List.NonEmpty APIの関数を使用することであるため、上記の実装は、クライアントが非空の不変条件に違反するのを防ぎます。不透明なニュータイプの値はトークンのようなものです：実装モジュールはコンストラクター関数を介してトークンを発行し、これらのトークンには内部的な意味がありません。それらを使用して有用なことを行う唯一の方法は、それらを使用するモジュール内の関数でそれらを使用できるようにし、それらに含まれる値を取得することです。この場合、これらの関数はヘッドとテールです。



このアプローチは、建設的なデータ型を使用するよりも効率的ではありません。これは、間違っている可能性があり、誤って無効なNonEmpty []値を作成する手段を提供するためです。このため、型安全性へのニュータイプのアプローチ自体は、望ましい不変条件が成り立つことを証明するものではありません。



ただし、このアプローチでは、定義モジュールの不変違反が発生する可能性のある領域が制限されます。不変条件が実際に成立することを確認するには、ファジング手法を使用してモジュールAPIをテストするか、プロパティに基づいてテストする必要があります。



この妥協は非常に役立ちます。建設的なデータモデリングを使用して不変条件を保証することは難しいため、常に実用的であるとは限りません。ただし、不変条件を壊すメカニズムを誤って提供しないように注意する必要があります。たとえば、開発者は、NonEmptyのGeneric型クラスから派生したGHCコンビニエンス型クラスを利用できます。

{-# LANGUAGE DeriveGeneric #-}

import GHC.Generics (Generic)

newtype NonEmpty a = NonEmpty [a]
  deriving (Generic)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

たった1行で、抽象化の境界を越えるための簡単なメカニズムが提供されます。

ghci> GHC.Generics.to @(NonEmpty ()) (M1 $ M1 $ M1 $ K1 [])
NonEmpty []
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

派生ジェネリックインスタンスは基本的に抽象化を破るため、この例は実際には不可能です。さらに、このような問題は、他のあまり明白ではない状況で発生する可能性があります。たとえば、派生したReadインスタンスの場合：

ghci> read @(NonEmpty ()) "NonEmpty []"
NonEmpty []
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

一部の読者には、これらのトラップは当たり前のように見えるかもしれませんが、そのような脆弱性は非常に一般的です。特に、より複雑な不変条件を持つデータ型の場合、モジュール実装でサポートされているかどうかを判断するのが難しい場合があります。この方法を適切に使用するには、注意と注意が必要です。

• すべての不変条件は、トラステッドモジュールのメンテナに対して明確である必要があります。NonEmptyなどの単純な型の場合、不変条件は明らかですが、より複雑な型の場合、コメントが必要です。
• トラステッドモジュールへのすべての変更は、目的の不変条件を弱める可能性があるため、チェックする必要があります。
• 誤用した場合に不変条件を危険にさらす可能性のある安全でない抜け穴を追加することは控えてください。
• 信頼できる領域を小さく保つために、定期的なリファクタリングが必要になる場合があります。そうしないと、時間の経過とともに相互作用の確率が急激に増加し、不変条件の違反が発生します。

同時に、その構造によって正しいデータ型には、上記の問題はありません。データ型の定義を変更せずに不変条件に違反することはできません。これはプログラムの残りの部分に影響します。型チェックは自動的に不変条件を適用するため、開発者の努力は必要ありません。プログラムのすべての部分がデータ型によって課せられる制限の対象となるため、これらのデータ型には「信頼できるコード」はありません。



ライブラリでは、より複雑なデータ構造を作成するために使用されるビルディングブロックを提供することが多いため、カプセル化を通じてセキュリティの新しい概念（newtypeのおかげで）を使用することは理にかなっています。このようなライブラリは通常、アプリケーションコードよりも多くの調査と精査を受けます。特に、変更の頻度がはるかに少ないためです。



アプリケーションコードでは、これらの手法は依然として有用ですが、時間の経過に伴う本番コードベースの変更はカプセル化の境界を弱めるため、可能な場合は設計を優先する必要があります。

ニュータイプ、乱用および誤用の他の使用

前のセクションでは、newtypeの主な用途について説明しました。ただし、実際には、ニュータイプは通常、上記とは異なる方法で使用されます。これらのアプリケーションのいくつかは正当化されます、例えば：

• Haskellでは、型クラスの一貫性の考え方により、各型は任意のクラスの1つのインスタンスに制限されます。複数の有用なインスタンスを許可するタイプの場合、newtypesは従来のソリューションであり、正常に使用できます。たとえば、Data.Monoidのnewtypes SumとProductは、数値型に役立つMonoidインスタンスを提供します。
• 同様に、newtypesを使用して、型パラメーターを挿入または変更できます。Data.Bifunctor.FlipのNewtypeFlipは、Bifunctor引数を交換して、Functorインスタンスが引数の逆の順序で機能できるようにする簡単な例です。

newtype Flip p a b = Flip { runFlip :: p b a }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Haskellはまだタイプレベルのラムダ式をサポートしていないため、この種の操作にはニュータイプが必要です。

• 透過的なニュータイプは、プログラムのリモート部分間で値を渡す必要があり、中間コードが値を検証する理由がない場合に、悪用を防ぐために使用できます。たとえば、秘密鍵を含むByteStringをnewtype（Showインスタンスを除外）でラップして、コードが誤ってログに記録されたり、公開されたりするのを防ぐことができます。

これらの慣行はすべて良いですが、型安全性とは何の関係もありません。最後のポイントはセキュリティと間違われることが多く、論理エラーを回避するために型システムを使用します。しかし、そのような使用が虐待を防ぐと主張するのは間違っているでしょう。プログラムのどの部分でも、いつでも値を確認できます。



あまりにも頻繁に、このセキュリティの幻想は、ニュータイプの露骨な乱用につながります。たとえば、私が個人的に使用しているコードベースの定義は次のとおりです。

newtype ArgumentName = ArgumentName { unArgumentName :: GraphQL.Name }
  deriving ( Show, Eq, FromJSON, ToJSON, FromJSONKey, ToJSONKey
           , Hashable, ToTxt, Lift, Generic, NFData, Cacheable )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この場合、newtypeは無意味なステップです。機能的には、Name型と完全に互換性があるため、12個の型クラスが生成されます。 newtypeが使用されている場合は常に、終了レコードから取得されるとすぐに拡張されます。したがって、この場合、型安全性にメリットはありません。さらに、フィールド名がすでにその役割を明確にしている場合、なぜnewtypeをArgumentNameとして指定するのかは明確ではありません。



このニュータイプの使用は、世界の分類（分類）の方法として型システムを使用したいという願望から生じているように思われます。引数名は一般名よりも具体的であるため、もちろん独自の型が必要です。このステートメントは理にかなっていますが、むしろ間違っています：分類法は関心のある領域を文書化するのに役立ちますが、それをモデル化するのに必ずしも役立つとは限りません。プログラミング時には、さまざまな目的で型を使用します。

• 主に、タイプは値間の機能の違いを強調します。NonEmpty a型の値は、構造が根本的に異なり、追加の操作が可能であるため、[a]型の値とは機能的に異なります。この意味で、型は構造的です。それらは、プログラミング言語内の値を記述します。
• -, , . Distance Duration, - , , .

これらの目標は両方とも実用的であることに注意してください。彼らは型システムをツールとして理解しています。静的型システムは文字通りツールであるため、これはかなり自然な態度です。それにもかかわらず、世界を分類するために型を使用すると、通常、ArgumentNameのような役に立たないノイズが発生するにもかかわらず、この観点は私たちには珍しいように思われます。



newtypeが完全に透過的であり、必要に応じてラップされて展開される場合は、おそらくあまり実用的ではありません。この特定のケースでは、区別を完全に除外してNameを使用しますが、異なるラベルが明確な状況では、いつでもエイリアスタイプを使用できます。

type ArgumentName = GraphQL.Name
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

これらのニュータイプは実際のシェルです。複数のステップをスキップすることはタイプセーフではありません。私を信じてください、開発者は何も考えずに喜んで飛び越えます。

結論と推奨読書

私は長い間、このトピックに関する記事を書きたいと思っていました。これはおそらくHaskellのニュータイプについての非常に珍しいヒントです。私自身がHaskellで生計を立てており、実際には常に同様の問題に直面しているため、このように伝えることにしました。実際、主なアイデアははるかに深いものです。



Newtypesは、ラッパータイプを定義するためのメカニズムの1つです。この概念は、動的型付けを使用する言語も含め、ほぼすべての言語に存在します。 Haskellを書かない場合、この記事の多くは選択した言語に当てはまる可能性があります。これは、私が過去1年間にさまざまな方法で伝えようとした1つのアイデアの続きであると言えます。型システムはツールです。どのタイプが実際に提供するのか、そしてそれらを効果的に使用する方法について、より意識し、集中する必要があります。



この記事を書いた理由は、最近公開された記事「 タグ付きはニュータイプではない」でした。..。これは素晴らしい投稿であり、私は完全に主要なアイデアを共有しています。しかし、著者はもっと真剣な考えを表明する機会を逃したと思いました。実際、Taggedは定義上新しいタイプであるため、記事のタイトルが間違った方向に進んでいます。本当の問題はもう少し深くなります。



ニュータイプは注意深く適用すると便利ですが、セキュリティはデフォルトのプロパティではありません。私たちは、トラフィックコーンを構成するプラスチックがそれ自体で交通安全を提供するとは考えていません。コーンを適切なコンテキストに配置することが重要です。同じ句がなければ、newtypesは単なるラベルであり、名前を付ける方法です。



そして、その名前はタイプセーフではありません！