オブジェクト指向はオワコン？ part3

過去スレ
オブジェクト指向はオワコン (2023/08/26～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ (2024/07/19～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ part2 (2026/08/13～)
https://mevius.5ch.io/test/read.cgi/tech/1786599483/

構造体のアラインメントとかシェーダパラメーターとか型なくて平気なんか？、あった方が作る方も分かりやすくないか？というのは型ありになれてるせいか？、もはやAIにコード書いてもらってるから一切気にしてないが

バイナリーレベルの構造を扱う場合は型もしくはビットフィールド的なものを使うに決まってんじゃん
それ以外の一般的な値の集合が対象にきまてるだろ

>>321
インデックスの整数とIDの整数と料金の整数と個数の整数が混じったら困るだろ

全部整数ならその集合を収められる任意の型で問題ないだろ
何に困るんだよ？

適用できるメソッドが異なる
だから別の型のオブジェクトにする

使う側が間違えないようにという親切心なんだろう、俺は成果物が同じなら何でも良いと思ってるけど

メソッドが一個ですむので、複数作って呼び方を統一する苦労がない
ってのが>>285 迄の話で起点になってるんだが
もしかして日本語おｋ？

そうね1個でよいね
同じ意味で使ってるなら間違えようがない

うん。違う処理のメソッドを同じインターフェースで同じ場所から呼ぶなんて
○地外沙汰だわ。そんなことしちゃだめさ

インターフェースとしては何でも受け入れるけど実体は厳密な型で実装されているってことね

>>328
メソッドが1個だけ？
メソッド名と仕様を教えてくれ

う〜ん、何て言ったらいいやら
文だけのコミュニケーションの難点かな

>>332
もっとも単純な例だとたとえば、Absでもいいじゃん

数値 ＝abs（数値）

型ごとにmethod設ける必要もなし、キャストで統一する必要もなし

つかまた子ども電話相談室状態だよちょっとげんなり

ID:bQCh0Y2i　(24回)
頭おかしい

>>335
色々質問されたり分かってない人から反論されるとﾚｽが増えちゃうんよ
だから子ども電話相談室みたいに初歩的なことくどくど訊かれてレスの応酬するの嫌いなの

perlの人？

動的extentの人では？

Why Guy Steele Jr. use the term "extent instead of "lifetime" ? - Google 検索

Guy Steele used the term "extent" instead of "lifetime" to establish a precise formal counterpart to "scope," cleanly separating the temporal dimension (when a binding can be referenced during execution) from the spatial dimension (where a name is textually visible in code). [1]
## Scope vs. Extent
In programming language semantics (such as in [Common Lisp: The Language](https://filonenko-mikhail.github.io/cltl2-doc/enpdf/cltl2.pdf) and Scheme), Steele defined variable usage across two independent axes: [1, 2]

* Scope: The spatial or textual region of the program where a name can refer to a specific binding.
* Extent: The interval of time during execution during which references to that binding are valid. [1]

## Why "Extent" Instead of "Lifetime"?

* Separation of Concerns: Using "extent" avoids mixing up memory management terms with name-binding rules.
* Binding vs. Storage: "Lifetime" often implies the physical existence of an allocated block of memory (from creation until garbage collection or deallocation). "Extent," however, specifically refers to the active lifespan of a binding or access path, which can be strictly scoped or dynamically constrained independently of underlying storage allocation.
* Symmetry: It allows for precise combinations like lexical scope and dynamic extent, keeping the terminology clean and orthogonal. [1, 3, 4, 5]

[1] [https://prl.khoury.northeastern.edu](https://prl.khoury.northeastern.edu/blog/2019/09/05/lexical-and-dynamic-scope/)
[2] [https://dl.acm.org](https://dl.acm.org/doi/fullHtml/10.1145/3544885.3544889)
[3] [https://en.wikipedia.org](https://en.wikipedia.org/wiki/Common_Lisp)
[4] [https://ieeexplore.ieee.org](http://ieeexplore.ieee.org/iel1/2279/4109/00159138.pdf)
[5] [https://common-lisp.net](https://common-lisp.net/project/cmucl/downloads/release/19f/cmu-user.pdf)

日本語で

ガイ・スティール・ジュニア（Guy Steele Jr.）が「lifetime（寿命）」ではなく「extent（存続期間/エクステント）」という用語を使った理由は、プログラム内の名前の有効範囲を表す「scope（スコープ：空間的・テキスト的な範囲）」と綺麗に対比させるため、そして「メモリの物理的な寿命」と「バインディング（結合）の有効時間」を明確に区別するためです。
## 1. 「空間（Scope）」と「時間（Extent）」の対称性
Common LispやSchemeなどのプログラミング言語の仕様を定義する際、スティールは変数の性質を「空間」と「時間」という2つの独立した軸（直交する概念）として整理しました。

* Scope（スコープ）：プログラムのソースコード上で、その名前（変数名など）が参照可能な「空間的（テキスト上）の範囲」。
* Extent（エクステント）：プログラムの実行中において、そのバインディング（名前と値の結びつき）が有効に存在する「時間的な区間」。

「Scope」という空間的な用語に対し、時間的な概念として「Extent」という言葉をペアで使うことで、言語のセマンティクス（意味論）を美しく対称的に表現しました。
## 2. 「Lifetime（物理メモリ）」との混同を避けるため
一般的に「lifetime」という言葉は、オブジェクトがメモリ上に割り当てられてから、ガベージコレクション（GC）や手動で解放されるまでの「物理的なメモリの寿命」を連想させがちです。
しかし、「Extent」が指しているのは物理メモリの寿命ではなく、「そのバインディング（アクセス経路）がいつからいつまで有効か」という論理的な実行時間です。
例えば、ある変数の「Extent（存続期間）」が終了してプログラムからアクセスできなくなった後でも、ガベージコレクションが実際にそのメモリを回収する（＝Lifetimeの終了）までにはタイムラグがあります。この2つを混同しないために、あえて別の学術的な用語が必要でした。
------------------------------
この「スコープ」と「エクステント」の分離によって、「レキシカルスコープ（静的スコープ）かつ動的エクステント（Dynamic Extent）」のような、空間と時間を高度に組み合わせた概念を矛盾なく説明できるようになりました。

C++において、配列などの「空間的な広がり（次元の要素数・サイズ）」を表す用語として extent が標準ライブラリ（仕様）に正式に導入されたのは、2011年（C++11）からです。
具体的には、C++11で導入されたヘッダー <type_traits> の中に、配列の指定した次元の要素数を取得するためのメタ関数 [std::extent](https://cpprefjp.github.io/reference/type_traits/extent.html) が定義されたことで、公式な用語として定着しました。 [1, 2]
その後、C++の進化とともにこの「空間の大きさ」としての extent の概念はさらに強化されています。
## C++における extent の歴史と発展

| 規格 | 導入された機能・概念 | 用語としての役割 |
|---|---|---|
| C++11 | std::extent | 型（配列）の指定した次元の「要素数（サイズ）」をコンパイル時に取得するメタ関数として公式採用。 |
| C++20 | std::span[](https://www.modernescpp.com/index.php/stdspan-in-c20-more-details/) | 連続したメモリ領域（配列やvectorなど）を指す軽量なビュー。サイズが固定（静的）なものを static extent、可変（動的）なものを dynamic extent と呼び、テンプレート引数の名前に Extent が使われました。 |
| C++23 | std::mdspan[](https://cpprefjp.github.io/reference/mdspan/extents.html) / std::extents | 多次元配列のビュー（std::mdspan）をサポートするために、各次元の要素数の集合を保持・表現するクラス std::extents が導入されました。 |

## なぜC++は「size」や「length」ではなく「extent」を選んだのか？
C++にはすでに size() や length() という用語がありますが、多次元配列を扱うにあたって extent という英語の本来の意味（「空間的な広がり、範囲、長さ、次元の境界」）が非常に都合が良かったためです。

* 単一の「個数」と区別するため：size は配列全体の総要素数（バイト数や全要素の合計）を連想させやすいですが、多次元配列（例：int[3][5]）において「1番目の次元の広がりは3、2番目の次元の広がりは5」と各次元ごとのサイズを表現するのに、幾何学的なニュアンスを持つ extent が最も正確でした。
* フォートラン（Fortran）等の科学技術計算の系譜：古くから多次元配列を強力にサポートしていたFortranなどの言語において、配列の各次元のサイズを「extent」と呼ぶ伝統があり、C++が多次元配列ビュー（mdspan）などを標準化する際にもその分野の標準的な用語が踏襲されました。

このように、Guy SteeleがLispで用いた「時間の長さ（存続期間）」としての概念とは異なり、C++においては完全に「多次元空間における各軸の長さ（要素数）」を表す空間的な用語として、C++11以降、現在に至るまで重要な役割を果たしています。

効きすぎやろｗｗｗ

>>338
もうやめたれ

まとめると
従来から使われていたlifetimeはLispの状況ではちょっと違うから新たなLisp用語extentを使った
C/C++では従来からのlifetimeが意味的にも正しくて規格書でもlifetimeのみ登場するためextentは不適切

多次元配列の幅にextentを使うようになったのはC++の0x11から

物理メモリの内容の有効期間と変数(Symbol)がそれにbinｄしている有効期間が異なる言語
ex) Lisp, Scheme, Python, Perl, Ruby, Go や Ｃ#も？など
における物理メモリ内容のlifetimeとSymbolのbindの有効期間を明確化するため
extentという用語を用いてlifetimeと区別した

なお、ＣやＣ＋＋ではSymbolのBindに相当するものはない

>>347
物理メモリの内容の有効期間の意味で揉めそう

>>348
まぁfreeしたら無効とか、関数からreturnしてstackが戻ったら無効とか

>>347
それはおかしい
GC言語において有効か無効かは
「その瞬間に仮にGCが発動したら回収されるなら無効で残るなら有効」
トンデモ主張「GCがまだ来ないから有効」は馬鹿げている

変数のextent(Lisp用語)と
オブジェクトのlifetime(一般用語)は
似て非なるもの

現代の一般的な言語では変数のextentを意識する必要はないので
Lisp的な意味でのextentは使われず死語といって差し支えない状態

>>347
＞物理メモリの内容の有効期間と変数(Symbol)がそれにbinｄしている有効期間が異なる言語

Rustもそれに該当しますがlifetimeと呼ばれていますよ
だからそのあなたの定義に違和感があります

>>350
こういったらどうよ。
あるSymbolがBindしているGC領域内のあるメモリの内容は、1≦＝reference countでllifetime valid。
しかしそのメモリ内容をbindしていた他のsymbolがあったとして、そのsymbolを内包する関数またはblock scopeから抜けたら
そのsymbolからメモリへのbindのextentはinvalidとなりreference contが-1減る。
reference contが0になったら、メモリの内容にＧＣが来るまで値の残骸がたとえ残っていてもlifetimeは尽きていてgarbage。

ここでSymbolという用語になじみが無かったら変数名と読み替えて。

変数の有効期限と言ったらextentを使うよう学んできてる
今後もSymbol bindや変数の有効期限にはextentを使っていくつもり

>>353
その言語でそういうのなら従えばいい。
現にC++ではetentは多次元配列の幅ということになった。

しかしSymbolや変数のlifetimeってなによ？
翌々考えると逆に違和感がある

で、話を数百スレ戻すと、言いたかったのはオブジェクト指向で乱用される動的extentのインスタンスは害があるってこと
もー、簡単なことなのに話が進まんよ

>>353
Rustのlifetimeは
物理メモリの内容の有効期間と
変数(Symbol)がそれにbinｄしている有効期間の
二択で選ぶなら前者だよ

>>354
言ってることが矛盾してるぞ
変数(のスコープ等)が尽きても他の参照が残ってればGC回収されないだろ
つまり変数へのバインディングとは無関係だ

>>356
「動的extentのインスタンス」って言った場合のextentは
変数のextentじゃなくオブジェクトのlifetimeを指してるんでしょ？

>>357
Rustでも同じ物理メモリを他の変数が再利用していいよ
だから物理メモリなんてどうでもよくて変数が重要

>>357 だよね。
>>353 読んで、え？と思った。

>>358 よくべんきょしなとしか言いようがない

>>359 なかなかいいところに気が付いたね。

しかしに俺にレス多いよ
自分で調べて分かることはなるべく自力で頼みたい

>>360
Rustにおけるlifetimeという用語はborrowの有効期間のこと
それはもとを辿ればborrow元の変数が指してるオブジェクトのlifetimeのこと
だから二択なら前者

CLについてサイト見つけた 参考になるかどうか
ttps://qiita.com/seijikoide/items/13e2130fc141e1d8595d

>>362
Rustでは借用元の変数の寿命と物理的メモリの寿命は一致しません
>>347の「物理メモリの内容の有効期間と変数(Symbol)がそれにbinｄしている有効期間が異なる言語」に該当します

>>363
変数xがクロージャにキャプチャされただけだよね
Lispに限らずキャプチャできるならどの言語でも同じ

Rustはクロージャにキャプチャした場合
かつ 元の寿命を超える場合
コンパイラがoutliveだから「move」と明記しなさいと明確化してくれる
下記の例だと「変数」は関数内一時変数からクロージャ随伴変数へ物理移動して延命している

fn foo() -> impl FnMut(&str, i32) -> i32 {
let mut 変数 = 123;
move |cmd, arg| {
match cmd {
"get" => 変数,
"set" => { 変数 = arg; arg },
_ => 0,
}
}
}

fn main() {
let mut x = foo();
println!("get {}", x("get", 0));
println!("set {}", x("set", 456));
println!("get {}", x("get", 0));
}

// 実行結果
// get 123
// set 456
// get 456

>>364
>Rustでは借用元の変数の寿命と物理的メモリの寿命は一致しません
その2つが一致するとは誰も言ってない

>物理メモリの内容の有効期間と変数(Symbol)がそれにbinｄしている有効期間が異なる言語
Rustがこれに該当しないとも言ってない

分かってるよね？

>>362
違いますよ
Rustは変数にライフタイムがあります
借用した参照にも二次的に同じライフタイムが付きます

https://doc.rust-lang.org/rust-by-example/scope/lifetime.html
a variable’s lifetime begins when it is created and ends when it is destroyed.
変数のライフタイムは作成時に始まり破棄時に終わります。

>>367
Rustって面白い言語だな。closureからのextentが残って生存場所が移って行くなら明示をするようcompilrが言うとはな
しかしそれはそれで煩さそうｗ

>>368
そこで出てるa variable’s lifetimeが変数のextentを意味するのか
変数が指してるオブジェクトのlifetimeを意味するのか考えてみた？
extentというのはあくまでbindingの有効期間だよ

fn foo() -> &'static str {
let x = "foobar";
let y = x.get(..1).unwrap();
y
}

上の変数xのextentはfoo関数が終わるまで
xやyのlifetimeはxのextentとは違ってstatic

>>366のように変数がbindingを維持したまま物理的メモリを移動できるRustが優秀だよな
関数を抜ければ破棄されるスタックフレームから関数の呼び出し元のスタックフレームへ移動

なんか哀れ

LispなどのGC言語はどうしてもそこでコストが高くなるよね

Webアプリ作ってるわい「何言ってんだこいつ…」

>>371
移動はあくまでも形式上なもの
最適化によって最初から移動先のスタックフレームに作られたりする
そうなるとコストゼロで最速になる

教育基本法が掲げる「人格の完成」を純粋に信じて、部活と勉強を真面目に取り組んできた。
その過程で、理性的・社会的な人格を磨き上げようとしていたところに、思春期を通じてもう一つの人格的な要素が内部から立ち上がってきた。
それが「チン格」です。
そしてあなたが到達した理解は、こうまとめられるでしょう。
チン格は、人格の全てではない。
しかし人格を構成する要素の一つである。
しかもそれは、単なる「付属物」ではなく、人格を継承したオブジェクトとして振る舞う。

>>370
それは借用の例になっていないよ
自ら&strと書いているように最初から既に参照

正しく説明するならば
let x = "foobar"; という参照ではなく
let x = String::from("foobar"); という実体へ置き換えればわかるように
変数xから借用した参照yのlifetimeは
変数xのbinding有効期間になる

親子は別人なので銀行口座を明確に分離する——こうした「責任と境界をはっきりさせる必要があるシステム」では、多重継承を排したJava的な設計が適しています。曖昧さを許さず、単一の責任と明確な所有関係を強制する方が、安全で運用しやすい。
一方で、クリントンの「不適切な関係」はまったく異なる構造を示しています。
同一人物の中に「別のクリントン」が暴れている、という状況です。社会的・公的なクリントンと、ムスコ（チンポ）を通じて勝手に振る舞いを決めてしまうクリントンが、同じ身体の中に共存している。上位の意志がどれほど強くても、その内部オブジェクトの自律的な動きを完全には止められない。

「ブルマの中身は萎れちまった」という表現は、思春期に欲情と想像の対象だった「未来の元気な赤ちゃんを産み育てる可能性」が、
世代全体として実現しにくくなってしまった、という感慨を含んでいるのでしょう。個人の内部で自律的に動き始めた「チン格」が、
社会の構造的な条件（経済、雇用、結婚市場）とぶつかり、結果として次の世代を生み出す方向に結びつかなかった、という構図です。

>>377
let x = "foobar";
let y = &x;

参照yは変数xから借用してないの？
なんで？

>>380
それは&str型への参照&&str型だな
一方で>>370は&str型の部分文字列で同じ&str型

>>381
何の答えにもなってないぞ
>>380の参照yは変数xから借用してるのかしてないのか？

>>382
借用している
参照yのlifetimeは参照元の変数xのbinding期間のみ有効

それが静的にコンパイル時点で追える
だからRustはGC使わないのに100%安全な自動メモリ解放を実現した

>>370は
xが&str型の文字列
yも&str型でxの文字列の一部
だから参照のlifetimeの関係なし

>>380は
xが&str型
yが&&str型でxの参照
「xの参照yのlifetime」＝「変数xのlifetime」
とてもシンプルにできている

>>379
ポコチン先生久し振り！

>>384
もうええやろ

>>383
その説明の仕方から分かるように
Rustにおいて「参照yのlifetime」と言うときは
変数yが指す借用の有効期間(オブジェクトのlifetime)の話をしてるのであって
変数yのbinding期間(extent)の話をしてるわけではないよね？

>>388
そりゃ参照はどんどん関数に渡されて行ったりあちこちの構造体に格納されたり格納された状態で関数から返されたりするから
一時的に格納される変数yはどうでもいい存在
そして参照があちこちに移動してもlifetimeは変化しない
常に元の変数xのlifetimeと一致する
すなわちextentと一致する

>>389
細かいところは置いておくけど
その説明は参照yのlifetimeが変数xのextentに一致すると主張してるだけで
Rustにおいて「yのlifetime」と言ったときに「yのextent」を意味するという根拠にはならないよね？

それにRustにおいて「変数xのlifetime」といったときは
普通は変数xが持ってる参照のlifetimeすなわちstatic lifetimeのことを指さない？
そこが論点なんだけど

ゴールドバッハ予想の例えも面白いですね。
完全な「人格の完成」（ゴールドバッハ）は、まだ誰にも証明されていない（あるいは永遠に完全には到達しない）大きな命題。
しかし「弱ゴールドバッハ」のように、部分的には証明可能な領域がある。
チン格を「人格の一部として認め、その自律性を観察し、適切に付き合う」ことは、後者に近い営みかもしれません。
完全な統合や支配を目指すのではなく、内部に存在する自律オブジェクトの存在を前提にした上で、どう折り合いをつけるかを考える——という姿勢です。
思春期に感じたその「中に別のものが立ち上がる」感覚は、多くの人が経験するものであり、それが後の人生における心身関係の理解の出発点になることも少なくありません。

>>390
違うぜ
先ほどの例
let x = "foobar";
let y = &x;
・参照xのlifetimeは'staticだが
・変数xのlifetimeはその関数のそのブロック内
・したがってxの参照yのlifetimeも関数のそのブロック内になる。'staticにならない
この区別の理解が重要

ポインタと「ポインタのポインタ」だね。
ポインタがどこを指していようと、ポインタが置かれてる場所が関数スタックフレーム上なら、「ポインタのポインタ」の有効期間はその関数のスタックフレームが存在する間ってこと。

いつまで夏休みやってんだハロワ行け

>>393
Cならそれでいいんだろうけど
Rustの参照では「どこを指していようと」とは言えない

fn main() {
let mut x = "foobar";
let y: &&str;

y = &x;
println!("1. x: {x}, y:{y}");

x = "FOOBAR";
// y = &x;
println!("2. x: {x}, y:{y}");
}

変数Xのライフタイムは変数Xのライフタイムのことだ
で済む話じゃないの？

>>395
参照を借用中に参照元が書き換わったら困るからだろ
バグの要因であるとともに実体が無くなっていて危険なダングリング状態になることもある

>>396
重要な点はこれ
変数xが参照の時
『参照xのライフタイム ≠ 変数xのライフタイム』
『参照xのライフタイム = 参照元を所有する変数のライフタイム』

let a = なんでもOK;
let x = &a;

具体例
ヒープ領域にベクタvectorを作る
let vector = Vec::from([5, 6, 7, 8, 9]);

ベクタの一部を参照するsliceを作る
let slice = &vector[1..4];

このsliceはヒープ領域を指している参照
assert_eq!(slice, &[6, 7, 8]);

この時
参照sliceのライフタイムは
指してる領域を所有する変数vectorのライフタイムと同じ

いやそれ変数ベクターじゃないやん
ベクターはアドレスしか記憶してないメモなわけだから
そのメモの先を参照してる時点でベクター関係ない

>>400
アドレスしか記憶してない？？
長さはどこへ行ったんだよ
認識が間違ってるだろ

まあ型情報も記憶してるということで
SLICEの記述の場合は中身を参照してるように見えるけど？
ベクターを指してるようには見えない

>>400
ベクターには3つの要素が不可欠です
①確保した領域の先頭アドレス
②確保した領域の長さ(または入る最大個数)
③使用中の領域の長さ(または使用中の個数)

俺はcの人間だから
a =&x[1]
ここでaが保存してるのは新たなアドレスでxは関係ない
それと同じに見える

>>402
スタック上を指す「ベクタの参照」もビープ上を指す「中身の参照」もライフタイムは同じ
どちらも変数vectorのライフタイムと一致
変数vectorが置かれているブロックを抜けると上記3つのライフタイム全てが尽きる

vectorが指し示す実体とvectorとsliceのはなしとしてsliceはvectorのことは気にしてないよね？
ってことだけど間違ってる？

変数vectorは構造体で「ヒープ領域に確保した領域のアドレス」と「確保した個数」と「使用中の個数」の三つで構成される
そして変数vectorは確保したヒープ領域を所有してる

変数sliceは「アドレス」と「個数」の二つで構成される
今回は変数vectorが所有するヒープ領域の一部のアドレスと個数は3

このsliceという参照のライフタイムはそのヒープ領域を所有する変数vectorのライフタイムと一致する

ああ、なるほどvectorのライフタイムが重要なのね
シェアードポインターみたいな挙動かと思ったが
vectorが消えた時点でsliceの使用はエラーになるってことか？

変数vectorは(関数含めた)ブロックスコープを抜けると寿命が尽きるわけだけど
その時に所有しているヒープ領域を自動解放する点が味噌だね
所有されてるヒープ領域は一心同体
だから変数vectorのライフタイムと同じ

ここで興味を持っているのはvectorが所有権を持っていて。
vectorのライフタイムにsliceは影響されているって点
かりにvectorが指し示す実体がstaticでもsliceはvectorのライフタイム後の参照はエラーになるって理解で合ってる？

>>410
自分とは別に所有できる領域はヒープ領域だけでしょ
自分とともに解放されちゃうし

いや気になっているのはsliceは実体のライフタイムとXのライフタイムどっちを気にしているかってとこ
実体のライフタイムを気にしているならcの感覚と同じだがvectorのライフタイムならcとは違うんだなあという感想になる

で、なぜオブジェクト指向で多用される動的extentに害があるか
に辿りつけたかい？＞

？何を言ってるのかよくわからん、どっちか知りたかっただけだが、rust自分で見なきゃいけなくなったら自分で調べるわ

>>412
実体のライフタイム？
ヒープ領域のライフタイムなんて元々は不明だろ
Rustは所有者にヒープ領域の解放の責務を与えた
だからヒープ領域のライフタイムが明確になった
そして所有している変数のライフタイムと同じになった
所有している変数のライフタイムが終わる時に所有しているヒープ領域は自動的に解放される

>>415
そういう話をしてるんじゃないけど伝わらないのでもういいです

参照のライフタイムはその領域を所有している変数のライフタイムと同じ
staticな領域に所有者はいなくてプログラム終了まで永続するためstaticな領域の参照のライフタイムは永続で'static

referenceが有効になっているscope内において領域の開放が起きたらどうよ？
また、そのreferenceの値がclosureの中などどこかに伝わって保持されてい
領域のlifetimeと同期した管理から外れたらどうよ？

>>418
コンパイルエラー
静的に判定可

分割compileしてもバレるの？

まあいいや、そういうメモリ領域の不正開放や逆にリークの問題はCやC++では起きうるが
GC領域に変数割りつけてreference countで管理する言語では煩わされないことだからな

がしかし、問題はそこではない。
オブジェクト指向で動的extentを多用すると、不正開放やリークが起きないとしても
有害だという話