スラッシュドット・ジャパン

もしかしたら「Spec#」がやっている事と同じ事の紹介かも知れませんが，ちょっと Spec# は詳しくないので，代わりに Curl の例を紹介させてくださいませ．

Curl は HTML の代わりだからプログラミング言語とは違うのでは？とか言われる事がありますが，とんでもない，れっきとした関数型チックでオブジェクト指向的なプログラミング言語であります．
「nullの無い世界」とはちょっと違いますが，Curl には，ある変数が null か否かをコーディングの段階ではっきり意識せざるを得ない仕組みが搭載されています．

|| ←これはコメントです．
|| Something クラスの変数 obj を宣言し，初期化しています．
|| {Something} は Something クラスのコンストラクタを呼び出しています．
{let obj:Something = {Something}}

|| null を代入しようとすると，コンパイルエラーとなります．
|| obj は null になる事が出来ない変数です．
{set obj = null} || error

|| クラス名の前に # をつけて宣言しておけば，null になる事ができる変数となります．
{let obj2:#Something = null}

|| obj を obj2 に代入する事は出来ます．
{set obj2 = obj}

|| obj2 を obj へ単純に代入しようとするとコンパイルエラー．
|| obj2 は null の可能性があるからです．
|| (上で obj を obj2 に代入していますが，コンパイラはそこまでは見ません)
{set obj = obj2} || error

|| {non-null} 関数をかませる事で，やっと代入できるようになります．
|| もしここで obj2 が null であれば，例外が投げられます．
|| さすがにそういうのは，コンパイル時には解決できないですわな．
{set obj = {non-null obj2}}

もちろん，わけのわからない人が何でもかんでも # をつけて null 可の変数ばかり使ってしまっては，ほとんど意味のない仕組みではありますけども．

Java でも @NonNull アノテーションが提案されていたりするし，C++ でも，スマートポインタをうまいこと改造して同様の仕組みを作り上げる事が出来るはずです （自分なりにはやった事があります．本格的にはやってませんが）．
これからの言語は，「null か否かを意識せざるを得ない仕組み」が常識になればいいのになーと思っています．

オブジェクトの寿命が変数の寿命よりも短い場合には、
実際には使われないにも関わらず参照が残っているために、
いつまでもGCされずにメモリ上を占有してしまう、
ということが、ままありますね。

特に、クロージャや例外や継続がエスケープしたりしたら、
変数の寿命とオブジェクトの寿命を一致させるのは至難の技でしょう。

なんだかんだ言って、null的な参照はどこかで導入されたと思います。

[null参照の考案は10億ドル単位の過ち？]であるならば謝罪と賠償を要求しよう！

#とか言う冗談を思いついたが、我が身の事を考えたらそんなことできないのでありました

かつてメジャー言語にポインタがなかった時代、実行時エラーの主役は0除算エラーじゃった。
（オーバーフローはチェックしてない環境も多かったから。）
けど、0除算エラーをなくすために0をなくそうという流れにはならなかったような。

ぬるぽや数値の0ほどじゃないけど長さ0の配列だのフィールドのないクラスだの空文字列だのも存在していることだし
なかったらやっぱり不便だと思う。

nullableの類いを構文に足すのは若干大袈裟な気もするなー。

＞不意なガベージコレクションを防ぐ効果があるかも

これが理解できない。

nullってことは、GC対象が無いわけだが・・・・

初期化のために1bit犠牲にして、

そんな事をしたらアクセス出来るメモリが半分になってしまうか、ポインタを格納するのに2ワード必要になってしまいます。

それよりポインタを作成した時に、中身が自動的にNULLの値になっている様な言語仕様にした方が良いかと。実際、Javaが似た様な事をしてます（Javaにはポインタ自体は無いけどオブジェクトのレファレンスが似た様な格好なので）。

1bitなんて使わなくても
0 = NULL
1 = 未初期化
それ以外 = 有効なポインタ
みたいなのでいいじゃない。Win32APIにもINVALID_HANDLE_VALUEとかありますし。

私もその辺がよく分からないのですが、
初期化されたか＝保持されている値が有効か否かのフラグを
アドレス値とは別に持たせるべきだったとでもいうのでしょうか？

そうではなくて、 (non-nullな)参照型が決してnullになり得ない言語仕様にしておけば良かった、 ということでしょう。

といっても、nullに慣れ親しんでしまった人には、 なかなか想像し難いものがあるかもしれません。 例えば、こう考えてみてはどうでしょう。 Javaにそもそもnull定数が無く(nullが予約語でなく、 たとえnullと書いてもコンパイル時に未定義変数エラーになる)、 すべての変数に初期化が必要で、 nullを返すようなライブラリ関数も無かったとしたら? 参照型変数が必ず有効なオブジェクトを参照するように初期化され、 オブジェクトを明示的にfree()/deleteで開放できないとしたら、 ポインタの先を参照した時、そこには必ず値があります。 ポインタをそもそもnullにする方法が用意されていないとしたら、 ポインタがnullかどうかのチェックをする必要もありません。

「えー、でも、それじゃどうやって、値が無いことを示すのさ?」

値が無いかもしれないことを示す必要がある時だけ、 nullableな型を使いましょう、というのが、答のようです。

少なくとも、 ホーア氏のプレゼンテーション概要 [qconlondon.com]にある Spec# [microsoft.com]は、 そのようになっています。

Spec#では、ポインタ型に2種類あって、 nullableなポインタ型か、non nullなポインタ型を宣言できます (C#では値型Tのnullable型をT?と書けますが、それと反対に、Spec#では参照型Tのnon null型をT!と書けます)。 この二つは、コンパイル時の型チェックにより、混ざらないようになっているので、 non nullポインタ型については、 実行時にnullかどうかのチェックをする必要はありません。 参照先に有効な値が存在することは、コンパイル時に保証されているわけです。 non-null型を使うのをサボってnullableなポインタばっかりにしたら、 結局今までと同じじゃん、という気もしますが。 詳しくはDeclaring and Checking Non-null Types in an Object-Oriented Language [microsoft.com](注: PDFです)参照、ということで。

実はこのようにポインタ型を2種類持つ言語はSpec#が最初というわけでもなく、 他にも例えば Ada [adaic.org]の 参照型も、"not null"を指定するかどうかで、2種類の参照型を区別できます。

Spec#は、独自の革新的なアイデアが入っているというわけではないものの、 過去の様々な言語の良いとこ取りを目指しているようですね。 Eiffel風の契約プログラミング [wikipedia.org]向きの 書法があったりして、なかなか面白いです。

件のホーア氏のプレゼンについては、 以前Lambda the Ultimate [lambda-the-ultimate.org]でも取り上げられていました。 そこでもいくつか興味深いコメントが付いていたので、参考にどうぞ。 Adaでもnot null指定ができるというネタはここから頂きました。 「nullableばっかり使ったら同じじゃん問題」に対応した言語については 別のコメント [slashdot.jp]に書いたのでそちらもどうぞ(長文ばかり(_ _))。

|∀ﾟ).。oO (この人、本当はホーア氏が嫌いなのではないだろうか・・・)

#ほ、ほあーーーっ！　ホアアーーーッ！

単純に、
{
StringData *foo=null;
...
  foo=bar();
...
  if(!foo) {
    fooが設定されてない＝函数barでエラー起こしたからあれこれやる
  } else {
    fooが設定されてる＝函数barで正常終了したからあれこれやる
  }
}
と言う、C++ではそこそこある（C的な)処理ロジックをやりたかったのでしょう。#1525645 [slashdot.jp]で既に出されていますが(^^;

Javaでこれを実際にやれば例外で飛ばされる以前にポインタで論理式を表記する事自体が反則なのでなんかすごく酷い邪道に思えてなりませんが…てか、C++と違ってC引きずらないでもいいんだからOOPと言うかカプセル化や継承をうまいこと使ってAPI統一すればいいものを…

# 以下、C++的に書くけど文法極めていい加減
Class functionTemplete {
bool results;
int ERR;
function main();
}
とかなんとかテンプレート作っておいて各実装はこのクラスの下位のクラス内ローカルな関数かこのテンプレを継承したクラスとして実装してねー、このテンプレに載せてある関数名と変数名は予約語扱いでこういう意味持たせておくインタフェース用の変数だよ。的な比較的ルーズなやり口が通用するというのに（あ、排他しないといけない可能性があるから、厳しくやるには変数いじらせる時はこの関数をこう叩けにしなきゃだめな場合も出るか）…そもそもJavaをわざわざ使う最大のメリットって、オブジェクトのポータビリティと同時にこの辺にある気がするのですが（あ、あくまでもいつもはCとアセンブラだけの人の偏見です ^^;）…

まぁ、一度手慣れた手法を崩すのが容易ではないのは分かりますが。