Julia: クレイジーなアイデア： `type`キーワードを変更する

typeという単語を他のコンテキストで使用できるようにするとよいでしょう。

私は一貫性のためにmutableが好きです。

これを行う場合は、 0.6含めることができるように、できるだけ早く行う必要があります。

これが発生する場合は、考える前に誰もが認識しているものを使用するよりも、 struct

また、 typeは少し厄介だと思います。 他の人に説明するときは、通常「構造体のように」と言うので、+ 1します。

これが発生する場合は、考える前に誰もが認識しているものを使用するよりも、 struct

immutableは構造体のようなものだと思いましたか？

mutable +1

immutableは、C構造体のメモリレイアウトがあります
typeはC構造体の可変性があります

したがって、構造体は両方に関連しています。 これを明確にするには、 structではなくmutable方が良いと思います。

すべての変数は変更可能です。 そのラベルを広く認識されている名前（ struct ）に割り当てると、私にはほとんどわかりません。

Fortranから来ている人にとって、キーワードtypeはすでに自然です。
Cから来た人にとって、キーワードstructは自然なことです。
immutable頻繁に使用する人にとっては、反対のキーワードmutableが自然です。

だから多分私たちはそれをそのままにしておくべきです。

struct{mutable}
struct{immutable}

または

record{mutable}
record{immutable}

より説明的な形式が必要な場合。

structを使用する場合、不変の構文はimmutable structすることができます（ struct部分は少なくとも最初はオプションです）。

Fortranプログラマーは「構造体」という用語に精通していると思います。

一貫性があるため、 mutable場合structが選択された場合、一貫性により、不変をconst structようなものに変更する必要がありませんか？ ;）

structとimmutable structは実際にはかなり良いと思います。 structは非常によく知られた用語であり、新しいキーワードを1つ追加するだけで済みます。 厳密に必須ではありませんが、 mutable structを許可することも理にかなっています。

structが名詞であることは利点だと思うことを明確にする必要があります。 これらに名前を付けるために形容詞だけを使用しない方がよいでしょう。

structをimmutable struct追加する必要があると、不要なラインノイズが追加され、これを入力する必要がないことに慣れていました。

音、Fortranにはtypeキーワードがあり、私たちと非常によく似た機能を果たしていると思います。 しかし、私はこれを変えることを嫌いではありません。

上記の@KristofferCは正しいです。これが何であるかを説明するときに、「構造体」と言っていることもわかります。 内部の議論においてさえ、 typeは問題でした。 誰かが「 xが型だと思う」と言うでしょうが、それが「 typeキーワードで宣言されたもの」を意味するのか、別の意味で「型」を意味するのかは明確ではありません。

これらの名前が実際にテーブルにある場合（ s/type/new name/は少し不快に思えます）、この機会を最大限に活用して、デフォルトの宣言を不変にすることをお勧めします。
したがって、 structはimmutable 、 mutable [struct]はtype.

考えたとおり、可変の別の可能な用語もRefである可能性があります。

これの一般的なCS用語は複合型であるため、別の可能な名前はcompositeになります。 しかし、私はまだmutable struct Fooとimmutable struct Fooよりもmutable Fooとimmutable Fooを好みます— struct （またはcomposite 、またはclass 、または何でも）は不要のようです。

：+1：名詞へ

Juliaのデータ型は非常に強力で微妙であり、「構造体」は少し単純かもしれないので、私はいつもJuliaのstruct typeよりもtype （私の背景は_C_ですが）アイデアのために。 また、これは新しい言語なので、ベテランのプログラマーが慣れている慣習に縛られるべきではないように感じます。「これを第一言語である人に説明するのに最適な言葉はジュリアです」も検討する必要があります。

また、これが何であるかを説明するときに「構造体」と言っていることに気づきます

ジュリアの「強力な型システム」を説明しながら、 struct Tを紹介し、 T::DataTypeと伝えると、 ::Type{T}を使用してディスパッチできると想像してみてください。 これは、バケツをさらに先に蹴っているだけだと思います。

名詞であることは利点です

：+1：名詞へ

「可変」のようなラテン語ファミリーの形容詞は、文法的にも自国語の名詞として許可されていることに注意してください。 そのため、「可変の名詞形は何ですか」と尋ねると、肩をすくめます。 しかし、私たちは常に「変数」と言い、ジュリアと言えば「これに不変のものを導入しましょう」と言います。 残念ながら、最初は英語の文法のゲルマン語のルーツのためにぎこちなく感じます-しかし、これは英語で非常に頻繁に起こります（私たちはフランス語とラテン語にも基づいているため）が、時間とともにそれに慣れます。

最後に、トピックは「クレイジーなアイデア」なので、これらのキーワードは多かれ少なかれ新しいDataType構築します。キーワードを完全に削除して、コンストラクターを使用するだけでよいでしょうか。

# Similar-ish to current
MyType = DataType(
    a::Int,
    b::Float64
)

# A DataFrame-like constructor
MyType = DataType(a = Int, b = Float64)

これらはccallように特別に（静的に）解析する必要があり、現時点ではトップレベルでのみ呼び出すことができると思います。 （また、すべての可能性をカバーするためにMutable <: DataTypeとImmutable <: DataTypeとBitsType <: DataTypeが必要かどうか、そしておそらくバインディングのためにconstが必要かどうかはわかりません）。

不変は構造体のようなものだと思いましたか？

イミュータブルはC構造体のメモリレイアウトを持っています
タイプはC構造体の可変性を持っています

そうです...私はSwiftについて考えていたと思います。

これが構造体とクラスの最大の違いです。 構造体がコピーされ、クラスが参照されます。 ...したがって、大きなオブジェクトの場合、参照としてではなく値として渡されます。

これはimmutable対typeように聞こえますが、これはJuliaバインディングのセマンティクスのコンテキストで変更可能にするための参照にすぎません。

DataTypeは、すべての名義型が含まれます： abstract 、ビット型、不変および可変構造体。 したがって、 typeをDataTypeに置き換えることはあまり明確ではありません。 また、「新人」のシナリオとは異なる結論を導き出します。 ::Typeと::DataTypeは、 type Tで定義されたもののスーパーセットを選択するため、名前が異なることはおかしなことではありません。 。 「 structはType一種です」は「 typeはType一種です」よりも意味があります。

私は形容詞が実際に名詞として役立つことができることに同意します。 たとえば、「これは不変です」と言うことができます。 私はそれらが不十分に説明的であると思います。 何が_であるかを伝えるのではなく、それが何であれ、それを変更できる/できないことを通知するだけです。

タイプにはstructureとmutable structureが好きです。 多分a = 1とmutable a = 1変数の割り当てです。 デフォルトでは、一貫性、省略形なし、および不変性が必要であるという考えを捨てます。

編集：デフォルトの場合の可変性では、 constではなくconstantかもしれません

または、キーワードの数が少ないバージョンは、 struct対const structます。 デフォルトですべての変数をconstにすることは、現時点では混乱を招きすぎると思います。

私はそれらが不十分に説明的であると思います。 それが何であるかをあなたに伝えるのではなく、それが何であれ、あなたはそれを変異させることができる/できないことをあなたに伝えるだけです。

これは良い点ですが、参照動作と「値」動作は、「構造体なのかビットタイプなのか」よりもはるかに重要で興味深いものだと思います。 （主にbitstypeがあまり頻繁に表示されないため、私が作成したすべてのJuliaタイプは構造体です）。 不変性は、バインディングセマンティクスと値渡しの結果にすぎません。

structとbitstypeの必要性を完全になくすために、 @ quinnjからのこのアイデアを含めることもできます。

immutable 32 Int32 <: Integer

または、ビット数として装飾されていないフィールドを持つことができます

immutable Int32 <: Integer
   32
end

これは（一般に名前付きフィールドと混合した場合）、必要に応じてパディングを挿入するのにも役立ちます。

次に、値型（現在は不変）と参照型（現在は可変ですが、将来的にはconstフィールドが含まれる可能性があります。これは、 mutableと呼ばないもう1つの理由です）のどちらかを選択するだけです。 値参照型にstructを使用すると、Swiftプログラマーが混乱します...

immutableが導入されて以来、 bitstypeがほとんど姿を消したのは事実です。 しかし、構造体とビットよりも区別することがたくさんあります。抽象型、タプル（これも不変）、そして将来的には不変になる可能性のあるレコードがあります。

immutableを最初に選んだのは、それが最も目立つ特徴であると感じたからです。他のオブジェクトとは異なり、それらを変更することはできません。 実際、それらは常に値によって渡されるわけではありません。 不変性とは、違いがわからないことを意味します。 一部のimmutableは、配列やその他のオブジェクトにインライン化されますが、そうでないものもあります。 不変性とは、違いが単純なjuliaコードに問題を引き起こさないことを意味します。 これは、C相互運用など、メモリレイアウトが本当に重要な場合にのみ問題になります。

実際、それらは常に値によって渡されるわけではありません

いい視点ね！ でも、それを変える計画はありますよね？

1.0に近づいているので、いくつかの将来性のある概念を反映した将来性のあるキーワードのセットが必要になると言っていると思います。 不変がインライン化されている場合、結果のセマンティクスに関して役立つ名前に名前を変更するのが妥当な時期であるように思われます（そして、それらのセマンティクスがFFIに役立つ場合は、さらに良いでしょう）。

abstract 、 Tuple 、および「レコード」（フィールド名で提案されたタプルのようなものを意味する場合）と混同される新しい具体的な型定義キーワードを人々が取得するとは思わない以前、「構造体」と呼ばれることも聞いたことがあります...）。

「値渡し」の概念の本当の目的は、 f(x) （ある意味で） x変更したときに何が起こるかという質問に答えることです：同じx呼び出し元が渡されましたか、それとも変更はローカルのみですか？ Juliaは、この動作に関して異なる型、引数、または関数を持ったことはなく、今後も持つことはありません（私は願っています）。 すべてが「共有によるパス」です。 私たちにとって、値渡しはABIレベルでのみ存在しますが、その議論はマニュアルのFFIセクションにのみ属します。 大きなオブジェクトではパフォーマンスが低下する可能性があるため、常に値で渡される、または常にインライン化される種類の型があるかどうかはわかりません。

とにかく、 immutableとmutableはキーワードの実行可能なオプションだと思います。

不変が導入されて以来、ビットタイプがほとんどなくなったのは事実です。

個人は通常、新しいビットタイプを作成する必要はありませんが、既存のビットタイプと一般的な不変の違いは、これらのABIが非常に異なるため、プリミティブレベルで非常に重要です。 新しい具象データ型を定義するときに、ほとんどの場合、ユーザーはビット型ではなく不変の構造体を必要とします。

FWIW、物事を変えないというサポートはtypeとimmutableはそのままで問題ないと思います。

（ do構文は私を悩ませますが... ;-)

すべてが「共有によるパス」です。

私はそれを尊重することができます-そして議論に感謝します。

すべてが「共有によるパス」です。

その点については、観察だけです。型宣言にconstキーワードが含まれている場合、 immutableは完全に不要になります。

type Complex{T}
    const re::T
    const im::T
end

（コンパイラーはこの型が自動的に不変であると判断でき、ユーザーはconst型を使用するとより高速なコードにコンパイルできることを理解できます）。 次に、 typeまたはstructが意味をなします。 混合の場合、 setfield!はconstフィールドで無効にできます。

typeとconst typeどうですか？ --typeキーワードは、structよりもエレガントに聞こえます。structとは、内部コンストラクターなどを持つオブジェクトではなく、技術的なメモリレイアウトを関連付けます。 複合型は「... Juliaで最も一般的に使用されているユーザー定義型...」であるため、「型が1種類の型」であれば、それほど悪くはないでしょうか。 「複合型」を使用した通信では、「抽象型」と同じように明確にする必要があります。 ラインノイズに関しては、「consttype」は「immutable」より悪くありません。

変数と型のconstの意味の（わずかな）違いについてはよくわかりません。 -いずれにせよ、タイプと不変は常に私に小さな精神的なしゃっくりを与えました。 ここでこの問題を見て良かったです！

structを使用する際の主な問題は、C / C ++から慣れていると自然に仮定する可能性があることです。これは、Juliaでは必ずしも当てはまりません。たとえば、可変複合型は値によって配列に格納されませんが、不変です。

immutableはtypeよりもエレガントに表すパラダイムは何ですか？ たとえば、同期プリミティブを必要とせずに、目的のフィールドを更新して元のフィールドから新しい不変をインスタンス化することにより、複数のフィールドの状態を同時にアトミックに「遷移」させます。

ディスパッチ/使用のポイントではなく、定義のポイントでタイプを2つの異なるカテゴリに分割する必要があるのはなぜですか（C ++のconstに）？ type / struct / compositeを使用して複合型を定義し、 Immutable{T}構造を導入して可変から不変に昇格させると、次のようになります。

type CompositeType end
f(x::Immutable{CompositeType}) = x
a = f(CompositeType())
b = f(a)

また、ここでabstractとbitstypeへの変更を検討できますか？ AFAICT「abstract」の使用法は形容詞であり、名詞ではありません。 すべての名詞、すべての形容詞など、タイプキーワード全体で少なくとも言語の一貫性が必要です。 bitstypeは、 bitsまたはprimitiveと表現した方がよい場合があります。

Juliaキーワードのスペル（またはセマンティクス！）の変更について議論するために、これをオープンスレッドに変えないでください。 この時点で、船はtypeとimmutableの基本的な_動作_で航海しました。 ここで提起された唯一の質問は、 typeとimmutableスペルが、それらの類似性をより適切に反映できるかどうかです。

現時点で最も合理的な2つのオプションとして、引き続きmutableとimmutableをサポートするか、そのままにしておきます。 それ以外のものは無意味に破壊的です。

@andyferris私はそのアイデアが本当に好きです。 structとconst組み合わせが良いでしょう。 そのようにすれば、すべてのフィールドにconstを書き込む必要がないように、（1） const structまたはconst typeと言うこともできます（2 ）したがって、フィールドごとの不変性の新機能をすぐに追加する必要はありません。 その機能を追加したい場合は、一貫した語彙を利用できるようにしておくとよいでしょう。

「コンポジットタイプ」を使用したコミュニケーションでは、明確にする必要があります

名前を付けるための私たちのお気に入りのテクニックの1つは、誰かに1つの文で説明し、次に1つか2つの単語が最も効果的であると思われる単語を選択することです。 だから私にとって、これはcomposite投票になります。

ディスパッチ/使用のポイントではなく、定義のポイントでタイプを2つの異なるカテゴリに分割する必要があるのはなぜですか（C ++のconstのように）？

それは簡単です。グローバルな保証を提供することです。 C ++では、誰かがconst以外の参照を持っている場合でも、「const」オブジェクトを変更できます。

また、抽象化とビットタイプへの変更をここで検討できますか？

提案する。 bitstypeに関しては、キーワードが使用されることはめったにないので、 bitsような小さな有用な単語を盗みたくありません。

immutable -> const typeも私には大丈夫のようです。 組み合わせることでtype > - compositeまたはstruct私たちは本当に解放したい場合は、 type 。

ただし、これによって発生するすべてのコードチャーンについては、特に@compatでサポートできないため、あまり満足していません。 これを行う必要がある場合、アップグレードパスは（1）0.6で新しいキーワードの同義語を導入するが、古いものを非推奨にしない（ @compatがないため）、（2）非推奨のようなものにする必要があると思います0.7の古いもの。

bitstype場合、これをprimitiveタイプと呼んではどうでしょうか。 現在の名前はan isbits composite type類似しているため、少し面倒です。

Juliaが他の言語の「def / func / elif」スタイルの略語のいくつかをしばしば避けてきた方法が好きです。 （Dn w abbrevs、kthx。）つまり、 mutableがstructに勝ちます。

FWIW、OCamlはレコードとバリアント（構造体とユニオン）とエイリアスにtypeを使用します。 標準MLはdatatypeを使用していると思います。

対称性は素晴らしいですが、 mutable説明が不十分だと思います。 immutableも、そのことについては（私はconst typeのアイデアが好きです）。

スティーブが指摘するように、これはコミュニティ全体でかなり悪いコードチャーンを引き起こします。 そして、その利点は疑わしいです。

私は間違いなくconst typeのケースを見ています; これはnet-1キーワードであり、タイプと不変の関係を明確にします。 ただし、他の方法でtypeを使用できると便利です。 その利点がなければ、変更を正当化することははるかに困難です。 ただし、このためのコードの更新は非常に簡単です。 typeの構文は、基本的に他のコンテキストでは使用できないようなものです。

composite / const composite +1。

primitiveとcompositeは、必要に応じてconstキーワードが追加された、優れた差別化要因だと感じています。

変更される可能性のあるいくつかのビットと区別するために（そして一貫性のために） const primitiveが必要ですか？ 対称的に

primitive        # something new... 
const primitive  # bitstype
composite        # type
const composite  # immutable

可変プリミティブ型であるという問題は実装する必要があります...（もちろん、これは後日になる可能性がありますが、それが起こっている場合はbitstype -> const primitive _ now_が必要です単純であるため、スタックにミュータブルを持ち込むための優れた「実践」ターゲットになる可能性がありますが、私はその専門家ではありません）。

同様に、コンポジットの個々のフィールドにconstを追加するというアイデアは、後日簡単に実装できます。さらに良いことに、これは重大な変更ではありません。

そのようにすれば、（1）すべてのフィールドにconstを書き込む必要がないように、（2）の新機能を追加する必要がないように、conststructまたはconsttypeも言うことができるようにしたいと思います。すぐにフィールドごとの不変性。 その機能を追加したい場合は、一貫した語彙を利用できるようにしておくとよいでしょう。

私には完全に理にかなっています。

compositeデータ型を調べたところ、少なくともAdaとVisualBasicもその下に配列型を包含していることがわかりました。 （それ以外の場合、少しランダムに見つかりました：Haskell：リストとタプル（ただし、定義が要求されています）; Python：リスト、タプル、dicts; Lisp：リスト、ベクトル、ハッシュテーブル、ユーザー定義クラス、構造）。

したがって、 typeような構造に対して、合成がどれほど正確であるか疑問に思います。 （しかし、私はコンピューターサイエンティストではないので、語彙や広範な視野が不足しています）。

うーん、そうかもしれません。この特定の種類のタイプは、常に構造体、構​​造体、レコード（またはクラスまたはオブジェクト）と呼ばれているようです。「複合」はより広い用語です。 http://rosettacode.org/wiki/Compound_data_typeには多くの例があります

typeを識別子として復元し、より具体的な名前を使用すると便利です。 〜0.6より前に書かれたほとんどすべての些細なパッケージの破損は非常に残念なことです。それをどのように評価するかはわかりません。

constキーワードを再利用するというアイデアは、グローバルスコープでのconst変数バインディングと、不変内部のフィールドのconstバインディングとの同等性を強調しているため、非常に説得力があります。 これは、 immutableよりも優れた統一性と優れた命名のようです。

typeを置き換える名前についてstructはあいまいさをかなり回避しているようです（「可変型」と「不変型」というフレーズはよく似ているようです）。

以下は私が推測するかなりいいように見えます：

struct A
    a::Float64
end

const struct B
    b::Float64
end

タイプを識別子として回復し、より具体的な名前を使用すると便利です。

私はこの感情を繰り返します。

名前を変更する場合、非推奨はどのように処理されますか？ typeとimmutableは、0.6、おそらく1.0でも有効であり、警告が表示されますか？ Compat.jlこれを透過的に処理できますか。 ネット上のかなりの量の文献（ブログ投稿、チュートリアルなど）には、警告が表示されます。これは、初心者にとってはちょっとした煩わしさです。

移行を容易にするために、通常よりも長くtypeとimmutableを予約することもできます。

私たちは1.0より前です：これを変更する時期は今または決してありません。 古いキーワードを長く利用できるようにすることは、スムーズな移行を確実にするために確かに良いことです。 実際の命名に関する議論と、移行が意味する苦痛を混同することはしません。

個人的に私はそれをstructと呼んでいます。 そうは言っても

実際の命名に関する議論と、移行が意味する苦痛を混同することはしません。

変更があまりにも痛い場合、私は変更に反対票を投じます。 1.0より前の変更は正当なものですが、発生した混乱と比較することはIMOが正しいことです。

@stevengjは、非推奨を行う方法について良い提案をしました。 @ amitmurthyも同じ結論に達したよう

先に進み、 struct投票します。 これは多くの話題や苦情を生み出す変更の1つだと思いますが、実際にはパッケージ/ユーザーコードを修正するのはそれほど難しくありません...それを行うだけで、人々はそれを理解するでしょう。

immutable -> const typeは最も抵抗の少ない道のようであり、IMOは間違いなく行われるべきです。 これは物事をより良く説明すると思います。

type -> compositeはtypeよりも正確ですが、 structよりも正確ではありませんが、 structよりも専門用語は少なくなります（新しいプログラマー）。 ジェフの「初心者に説明する文を書く」テストに合格し、 typeキーワードを回復します。欠点として、 compositeが他の言語で表示されるとは思わないので、一人で行くこと。

type -> structが最も正確ですが、おそらくstructureは略語よりもきれいです（略語をstructように醜いと考えようとしています） eye()は、英語の観点からはかなり嫌な伝統だと思います）。

bitstype -> primitiveは、 typeが変更された場合に意味があります。

@tbreloffは正しいです-コア

明示的に変更する必要がない限り、 immutableを標準にする必要があるので、名前を変更する必要があるかどうか疑問に思います。

• immutable -> struct
• type -> mutable

次に、共通/予想される名前がベストプラクティスであり、可変性を要求するための明示的で明確な名前があります。

bitstype -> primitiveも好きです...

constをデフォルトにするべきではないと思います。 機能を減らす最適化をデフォルトにするべきではありません。

structおよびconst struct +1。

compositeという用語は少しわかりやすいですが、 structは短く、非常に一般的に複合型として知られています。

bitstypeようにめったに使用されないものについて、実際の単語を盗むことはしたくありません。 たぶんprimtypeまたはprimitivetype ？

bitstypeをprimitiveような明らかに適切な名前に変更しない場合は、そのままにしておく方がよいと思います。

-1からstruct 。 Cプログラマーと話をしている場合を除いて、この用語を使用して型定義とは何かを説明することはしません。次に、レイアウトに互換性があることと、それらのプロパティを比較/対比することだけを説明します。

-1からconst 。 Cは、キーワードを最小限にするというこの方向に進みました。現在、状況依存の意味を持つ多くのキーワードで立ち往生しています。 constがこれらの型の重要なプロパティであるとは思いませんが、（参照型ではなく）値型であると思います。

別の方向に進んで、キーワードnewませんか？

new abstract Abstract
new value Value <: Abstract
    Value() = new()
end
new primitive 8 BitsByte <: Abstract
new record Object <: Abstract
    Object() = new()
end
new function WhyNot # equivalent to `function WhyNot end`

「値型」の問題点は、言語に精通している人だけが理解できることです。 新規ユーザーの場合、フィールドが不変であるという事実は、フィールドがすぐに直面する_意味論的_事実です。 他のすべては実装の詳細です。 だから私はconstを好みます。

レコードをどこに使用するかはわかりますが、正直なところ、この用語はstructよりも一般的ではないと思います（「recordtyperuby」と「structtyperuby」をグーグルで検索したり、pythonやperlなどに置き換えたりしても他の非C言語）。 recordは非常に便利な英語の単語であり、キーワードとして予約するのは恥ずべきことですが、 structはプログラム内の他の単語には必要ない可能性が高いという問題もあります。

structは非常に一般的に使用されています。 それが使用されるロゼッタコードを見渡す：

algol、C、C＃、C ++、lisp、D、elixir、forth、go、maxima、racket、rust、seed7、swift、visual basic（ structure ）

recordは次のユーザーによって使用されます。

ada、clojure、delphi、pascal、erlang、icon、modula-2、いくつかのスキーム

recordは古い言語で好まれているようです。 最近、関数型プログラミングの人気が高まるにつれ、構造的に型付けされたレコードを参照する傾向があります。

興味深いことに、seed7はnew structます。

Aは見て悲しいビットstructこれまで持っていた言語にそれを作る（悪い？という本当に言葉を完了するために余分な3つの文字です） functionの代わりにfunc 、 等々。 それは誰もが言語を拒否しようとしているものではありませんが、それでも...

structureは、実際にはPL / IおよびVisualBasicで使用されます。 VBにもstructure immutableます。 しかし、 structは非常に一般的であり、それ自体がほとんど新しい言葉になっていると感じています。

ここにもネイティブスピーキングの問題があるのだろうか。 私にとって、この文脈でstructという言葉に非常に慣れているのは、 structure 、それはもっと奇妙に感じます。 同じ理由で、 funcはひどく聞こえ、 function自然に聞こえます。

structは、さまざまなプログラミング言語で使用されているため、自己完結型の用語になりませんstructureという単語は（少なくともドイツ語のネイティブとしての私にとっては）はるかに抽象的なものです。 たとえば、その型階層には特定の「構造」があります。

funcは、私にとっては自己完結型の用語ではなく、単なる略語です。

funcは私にとって自己完結型の用語ではなく、単なる略語です。

構造体は単なる略語ではありませんか？ それは文字通り構造の略ではありませんか、それとも私は単に用語を誤解しましたか？ あなたはfuncよりもそれに慣れています。 多くのことは「自己完結型の用語」であり、多くの言語に共通していますが、それは必ずしもジュリアが伝統に従うべきであるという意味ではありません。 それから、それは何が良くも悪くも争うだけであり、それはほとんど好みの問題です。

とにかく、私はmutableを好むので、それが構造体であるか構造体であるかはあまり気にしません。 ミュータブルは、現在のimmutableに対して常にconst書き込むことを回避します。

しかし、最終的にstruct 、さらにはstrct 、 stct 、 strctrなったとしても、Juliaを他の言語に変更する可能性はほとんどありません。私の仕事なので... :)

これが英語で意味をなさない場合は申し訳ありませんが、 structはconstruct略語ではありません。 少なくともドイツ語では、 Konstruktという単語は、複合型とは何かを説明するのにはるかに意味があります。

英語では、 constructが名詞なのか動詞なのかがわからないため、英語ベースのプログラミング言語での使用がおそらく妨げられています:)ドイツ語で大文字を使用すると便利です。

structは、TV、ASAP、LOLが単語であるのと同じように、独自の単語です。 「構造」と言われることはめったにありません。 私の経験では、この単語は話し言葉と書き言葉の両方で「構造体」です。

ところで：Matlabはstructという単語を使用していますが、それが違いを生む場合は。

上記のように、OTOHはC＃およびSwiftではstructが値型に対応します（ class struct ）。 したがって、可変型と不変型の両方に同様の用語を使用しても、これらの言語に精通している人々には実際には役立ちません。 それが決定的なポイントかどうかわからない…。

mutable / immutableは最も明確な選択のように聞こえますが、これは初心者にとっては非常に明白なはずです。

structを使用する言語が多数あることを考えると、その名前を使用するために同じセマンティクスを持つ必要はないと思います。

私はtypeとconst typeが一番好きですが、それでもtypeキーワードが解放されるわけではありません。 typeの予定がわからないので、どれくらいの費用がかかるのかわかりません。

ただし、 type部分はすでにabstract 、おそらくmutableとimmutableを単独で使用するのが最も理にかなっています。 そして、 immutable structよりもタイピングが少なく、小さな変更があります（タイプ->可変）。

単語の構造は（少なくともドイツ語のネイティブとしての私にとっては）はるかに抽象的なものです。

言語について議論している間、誰もがstructという略語の量を過小評価しています。 「データ構造」の略です。 同様に、 typeは「データ型」の略です。 リンクリストなどのように、配列またはバッファもデータ構造であるとあえて言いますが、 structは、最初の一般的なデータ構造の1つとして初期のルーツを持ち、コンピューティング内でそれが持つようになりました。それ自体のより具体的な意味（したがって、英語またはその他のネイティブのプログラマーにとっては、 structureほど抽象的ではありません）。

-1からstruct 。 Cプログラマーと話をしている場合を除いて、この用語を使用して型定義とは何かを説明することはしません。次に、レイアウトに互換性があることと、それらのプロパティを比較/対比することだけを説明します。

私はstructについてまさにこのように感じています。 特別な理由もなく、ジュリアに新しい用語を導入するつもりだと思います。

-1からconst 。 Cは、キーワードを最小限にするというこの方向に進みました。現在、状況依存の意味を持つ多くのキーワードで立ち往生しています。 constがこれらの型の重要なプロパティであるとは思いませんが、（参照型ではなく）値型であると思います。

ジェフは上記で（非常に親切に）説明しましたが、意味的には値や参照などは関係ありません。これらは実装の詳細であり、意味ではなく、将来の黄金時代には_私たちは気にしません_。 コンパイラーが望む方法で物事は「共有によって渡される」（必要に応じていくつかのFFI保証付き）。 過去数日間、私はすでにそれを「魔法による共有」と呼ぶようになりました。これは私にとって啓示であり、（理想的には）考える必要のない精神的なプレッシャーを和らげていると感じています（ @vtjnashは、私が値と参照にどのように苦労してきたか、そしてこれらがコンパイラやGCなどによって他のパッケージやスレッドにどのように実装されているかを見てきました。

バインディングは変更することも一定にすることもできます（ constを使用しますが、 constantもかなりかわいいです）。 同様に、複合データ型内のフィールドのバインディングは、変更されるか、一定になります。 これが、以前にconstを各フィールドに明示的に添付することを提案した理由です。これにより、セマンティクスが明確になりました（少なくとも私にとっては）。

IMOは、このことについて話すために「可変性」や「不変」などの派手な言葉を使用する必要はありません。 何かが新しいオブジェクトにリバウンドされるか、そうでなければそれは一定です。 structやimmutableような複雑な英語の単語の必要性を、（コードだけでなく）Juliaについての談話から完全に取り除くことは、良いこと（目標でさえ）と見なされるべきです。

また、「struct」はそれ自体の単語（Cでの意味）であるのに対し、「structure」はおそらく「データ構造」であるように感じます。レコードタイプを意味する場合は、「struct」と言うからです。 しかし、ここではCのルーツを示しています。

それは一般的なLispでもあります。 defstruct 。

ここにある他のほとんどのポイントよりもおそらく些細なことですが、バイクシェディングをしている限り、声に出して話すと、 immutable objectとa mutable objectというフレーズimmutable objectうっとうしいほど似ています。 それは、ジュリアの型システムについての会話を必要以上に難しくするでしょう。 編集：これはすでにこのスレッドで取り上げられているようです。

+1からtype -> structおよびimmutable -> const struct 。 特に大雑把な説明の後で、これに混乱する人に会ったことはないと思います。

type置き換えは、v0.6では現実的であり、v0.8では非現実的です。 これを行う必要があります。 明確なコミュニケーションと表現の速さのために、ジュリアの自然な才能をよりスムーズにし、向上させる機会です。 タイプは、機能するソフトウェアを作成する上で非常にうまく機能します。 典型的なもののより良い命名は強力に共鳴し、ジュリアにとってより名高い未来をもたらすでしょう。

struct未使用のままにしておくことをお勧めします。 Cでは、構造体は、型が固定されたフィールドの固定シーケンスの構文コンテナーです。 ジュリアはCではなく、C主義をジュリアンの言説に引き込むことは、ジュリアの側面を概念化するための最良の使用法とより良い方法についての真剣な議論の外にジュリアの儚い性質を押しやるでしょう。

また、「不変」と「可変」は視覚的に一致しすぎています。 私たちはもっとうまくやれる。

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@JeffreySarnoff余談ですが、コミュニティの基準によれば、ジュリアを「それ」と呼ぶことが好ましいです。 私がそれについて言及すると思っただけです。 🙂

@ararslan Juliaに関するコミュニティの標準ガイダンスが変更されたようで、現在は文学代名詞の適用を避けています。 これを私に知らせてくれてありがとう。 ：クリケット：

フェミニンな代名詞を使用すること自体は悪くありません（そして多くの言語で避けられません）が、多くの人が「彼女」という用語の使用からジュリアを暑い日として話すことへとジャンプするのは魅力的だと感じているようです。誘惑をできるだけ避けてください。

THX

16:29の木、2016年11月3日には、ステファンKarpinski [email protected]
書きました：

女性の代名詞を使用すること自体は悪くありません（そして多くの場合避けられません
言語）、しかし多くの人が使用からジャンプするのは魅力的だと感じているようです
ジュリアを暑い日として話すための「彼女」という用語は、
誘惑をできるだけ避けてください。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
。

当面の問題に関して、私は個人的に何が最善の変更であると考えるかについて決定していません。 しかし、それはジュリアの素晴らしい_type_システムについて話して、キーワードはタイプを構築するために使用することを指定するには、私には奇妙に思えるん実際にはstructではなくtype 。 代わりに構造体として型について話すことを人々に奨励するかもしれないと思います。最終的には、ジュリアの驚くべき_struct_システムについて議論するなど、ジュリアを説明するために使用される言語の変化につながります。

タイプの作成に使用されるキーワードは、実際にはタイプではなく構造体です。

しかし、キーワードは実際には型を構築することではありません---たとえば、式Tuple{Int}も型を構築します。 現在type定義されているものが常にstructと呼ばれると、 Realが型であるかどうかについて混乱が生じることはなく、 Union{Int8,Int16}はタイプなどです。

はい、私は以前のメモを編集していて、今それについて書いています。 それはそのようになります
ジュリアとの「世話と給餌」に広く有害
表現力と簡潔さの将来の発展。 ドアは
ジュリアの型システムの考慮を正当化するために開かれました
C構造体の足場、戦争は失われます。

4時38分PMに木、2016年11月3日には、アレックス・アルスラーン[email protected]
書きました：

当面の問題に関しては、私は個人的に何を決めていません。
最良の変更を検討します。 しかし、私が話すのは奇妙に思えます
ジュリアの驚くべき_type_システムそして、キーワードが
型の構築は、実際には型ではなく構造体です。 私はそれがかもしれないと思います
代わりに構造体として型について話すように人々を促し、最終的には
ジュリアを説明するために使用される言語の変化へ、例えばジュリアの議論
素晴らしい_struct_システム。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
。

現在type定義されているものが常にstruct sと呼ばれていれば、 Realが型であるかどうかについて混乱が生じることはなく、 Union{Int8,Int16}はタイプなどです。

現在、それに関して混乱はありますか？ おそらく私はそれについての議論を逃したかもしれませんが、私には多くが明白に思えたと思います。

@ararslan ： typeという用語は、現在構築されているものの総称です。 現在typeキーワードを使用して構築しているのは、複合型で構成される構造です。 しかし、Juliaには、 typeキーワードを使用して構築されていない他の多くのタイプがあります。

いいえ、現時点ではそれほど混乱しているとは思いませんが、キーワードstructを使用した場合、すべてのジュリアタイプが構造体であるとは誰もが思いません。

さて、良い点です。

Union {Int8、Int16}はタイプです

ああ。 Unionも存在することを忘れていました。 これにより、 struct （ Struct ？）の議論がより説得力のあるIMOになります。 それでもmutableとimmutableは好きではありません。

私は_struct_が無知であることに気づき、ジュリアをそれに運ぶことは、時間の経過とともに、進化する時代精神を引き下げるだろうと本当に信じています。 原理は、動いているビットの説明と、高次の融合およびより深いゲシュタルトとしての計算の多分表現との間の拮抗作用です。 structを使用しても、構造体が重要ではないタイプについて誰もが考えるようになるわけではありません。 ...私に誇張させてください...

アインシュタインについて特許係員として書くことは、彼の貢献に対する評価を弱めるとは言えません。 アルバート・アインシュタインへの言及が特許係員としての彼の時間の重要性を強調するコースでは、数人以上の学生が将来の会話でその感覚を抱くであろうということにはなりません。 soあるということは、新しい学校に引っ越した後、それがsoだけで動作することを保証するものではありません。

_struct_を使用するための説得力のあるケースがある場合は、次のいずれかのより良いケースがあるはずです。

structureは、パーツの意味のある相互関係であり、情報に基づいた構成です。
constructは、関連性の便利な構造化であり、価値を高める設計です。

不変のstructureは永続的なコンポジットです
可変のstructureは、固定されていない事前選択です
不変のconstructは確立された偶然性です
変更可能なconstructは、コンテキストに対する意図的な制約です

「ビットインプレースアンドスルーゲート」の話し方と「データ構造化によりオントロジー情報が明らかになる」の両方が必要であり、それを変換修飾子の話し方として利用できるようにすることができます。 CSの才能であるコミュニティ参加者や、大規模なプログラミングを行う他のほとんどのドメインエキスパートは、バイト、メモリ、ロジック、指示された操作などを徹底的に処理します。欲求、創造性、可能性、想像力を生み出すもう1つの方法は、うまく機能するソフトウェアになります。仕事の価値は十分にあります-それはあまり共有されていません。 用語の命名に関する決定は、その話を奨励するために到達する必要があります。

classとimmutableどうですか？

Delphiのクラスを知っていて、ここでは無理だと思っていましたが、マルチメソッドのあるニース言語ではキーワード（ link ）として使われています。 そして-私がマニュアルを正しく読んだら-HaskellとDylanでも。 それは「クラスはタイプの一種です」テストに合格しますが、それでもかなりあいまいです（今日の「タイプ」として）、私が好きなものです。 15：00〜15：20分の「配列と反復の概要」ビデオで、Tim Holyは（偶然に）「クラス」と言っています。これは重要ではありませんが、それでも、ジュリアのコンテキストではクラスが完全に異質ではないことを示しています。

それ以外の場合、 reftypeとimmutable ？ reftypeの用語は最初のコメントで言及されており、それ以降無視されています。 どうして？ 私にとって、それは非常にいい音で、タイプを解放し、参照の意味を伝えます。

（「new」キーワードの目的がわかりませんでした。「new」を変更せずにすべての行で省略できませんでしたか？「value」および「record」という用語はキーワードであり、現在使用されている「immutable」を置き換えます。と「タイプ」、そうですか？）

@swissrこれら2つのタイプの唯一の違い（ほとんどのユーザーが知っておくべき）は、一方のフィールドは変更でき、もう一方のフィールドは変更できないことです。 それらの名前がそれらの唯一の意味上の区別を示していれば論理的です。 （前述のように、値と参照を使用する実装は流動的です。たとえば、改良されたコンパイラは、最適化として参照によって大きなisbits型を自動的に渡す可能性があり、逆に、特定の状況では小さな可変変数がスタックに移動する可能性があります）。

typeとstructについては、 abstract 、 Union{} 、 typealiasなどの抽象データ型を作成できることがわかります（ Tuple{}の場合、それが新しい型であるか、パラメーター化された型であるかは議論の余地があります）が、実際には_ユーザー定義の具象型_のみがbitstype 、 typeおよびimmutable 。 これらの構文は、それらが何らかの形で含むデータを定義するという点で抽象的な定義と紛れもないものであり、抽象的な定義はそうではありません。 immutableをconst typeに変更すると、状況が明確になります。

素人の言葉で議論されるプログラミング言語を作成する機会があるとき、私は言語と専門用語struct伝播について心配しますが、唯一の理由は伝統です。 これが役に立たないと思う例は、 Symmetric{Matrix{T}}ようなラッパータイプを作成する場合です。「このstructを1つのフィールドだけで作成しました。 「私が言うことができたときに"これは...私が作っSymmetricラッパーtypeのためにMatrix "（その文の半分は、実際の構文であることをメモしてください）。 「ラッパー構造体」？ ちょっとばかげているように聞こえますが、1つのフィールドで構造体を作成するのは誰ですか？ さらに言えば、フィールドのないシングルトンはどうですか？ typesとimmutablesのかなりの部分は、（重要な）データ構造を作成するために定義されているのではなく、ラッパーとシングルトンを備えた強力な型とディスパッチシステムを使用するという明確な目的で定義されています。 IMOこれは、ジュリアの最も興味深く、強力で表現力豊かな側面です（それが_速い_という事実と組み合わされています）。

structは、構造体を使用して特性などを実装できることを知っている経験豊富なテンプレートC ++メタプログラマーにすぐに明らかになると思いますが、それは少し残念です。

「種類」は型理論においてかなり特定の技術的意味を持っています。

目標/利点がtypeを解放することである場合、どうでしょうか。

const datatype  # immutable
datatype        # type

これらは具象型であるため、おそらくデータが含まれています。これは、 DataTypeを作成する（多くの）方法の1つです。

「種類」は型理論においてかなり特定の技術的意味を持っています。

ウィキの紹介はType{} （ DataTypeとTypeConstructor 、 Unionなどを受け入れる）とまったく同じように聞こえます（編集：そのような変更だとは思いません混乱させる価値があります）

kindはここでは正しい言葉ではありません。

ほとんどの場合、最善のアプローチは単にフィールドを学ぶことだと思います
あなたのものに置き換えようとするのではなく、標準的な語彙
推測が簡単になります。

この決定は非公式のスピーチには影響しません。 あなたはまだ賢明に「私は
タイプを定義しました」。より具体的なキーワードを使用すると、次の場合に簡単になります。
あなたは正確である必要があります。

フェアポイント、ジェフ。 const structとstructはimmutable対typeよりも改善されると私は_do_と思うことに注意してください（しかし、それは私たちが検索すべきではないという意味ではありませんさらに良いもの）。

構造体は、構造体または構成概念として、どちらでもないか、または両方として認識されると思いますか？

@andyferrisの「class」と「reftype」のコメントは、「const type」も気に入らない、またはconst structとstructが改善されることをサポートしないという意味ではありませんでした。 'const'を回避し、 'immutable'を保持し、 'struct'を除外したい場合に、考えられる用語を探すもう1つの試みでした（言及された実装を認識していましたが、80plus％の場合は問題ないと考えました） 。

fieldtype （またはfieldstype ）はどうですか？ これはbitstypeと並行しており、 fieldnames()と一致しています。

グレン、
私は真実らしさが好きです。 何かが単数形または複数形になる可能性がある複数形を使用することが適切であるため、fieldstypeの方が適しています。
-ジェフリー

classは大丈夫かもしれません。 オブジェクト内のメソッドを持つクラスベースのOOと関連付けられているため、当初は拒否しました。 struct方が正確だと思います。

structは何よりも短いとは思いません。 これは、この時点でこれらの種類のデータ構造と呼ばれているものです。 ややおかしなことに、lispにはconsがあります。これは元々 construct省略形だったかもしれませんが、人々はそれをすぐに忘れて、「conscells」について話し始めました。

classを拒否し続けるべきだと思います。 その用語を使用すると、ジュリアスタイルに反する多くのOOP期待が生まれます。

structは何の略語でもありませんが、Cの構造体への暗黙の参照が、Juliaの値型であることを暗示しているのではないかと心配しています。もちろんそうではありません。 そのために、私は現在record少し傾いています。これは、直接的な意味合いがはるかに少ないためです。

明確ではないかもしれない点を明確にするために、 const recordまたはconst structは、すべてのフィールドにconstをマッピングするための短い意味で解釈される場合にのみ実行可能だと思います、個々のフィールドをconstとしてマークすることをサポートしたいことを意味します。 だから私が言っているのは、私たちはこれらを持つことができるということです：

record T0
    f::A
    g::B
end

record T1
    const f::A
    g::B
end

record T2
    f::A
    const g::B
end

record T3
    const f::A
    const g::B
end

const record T4
   f::A
   g::B
end

ここで、T3とT4は実際には同等のタイプを記述しています。つまり、 const recordと書くことは、すべてのフィールドがconstことの省略形です。 これが解釈でない場合、これはすでに概念の混乱の一般的な原因であり、その用語の混乱に追加すると、問題を解決することはできないため、不変性と恒常性の混同は一種の危険だと思います。

ここで、T3とT4は実際には同等のタイプを記述しています。つまり、constレコードの書き込みは、constであるすべてのフィールドの省略形にすぎません。

const record immutable意味を意味するようにすると、これは正しくない可能性があります。 const recordは、どのフィールドも変更できない参照型を記述します。 一方、現在のimmutableは値型です。

record説明については、 https： //github.com/JuliaLang/julia/issues/19157#issuecomment-257942059と次のコメントを参照して

@vtjnashこれは良い点ですが、 immutable参照が含まれている場合、

recordがあまり一般的ではないという事実は問題ないと思います。名詞と動詞の両方として有用な単語であるという事実は、より問題があります。

nupleどうですか？ もちろん、「名前付きタプル」の略です。

私は上記の提案が好きです

const datatype  # immutable
datatype        # type

これまでで最高。 それは歴史的な荷物で古い言葉を持ち込むことを避け、私には完全に明白に思えます。 確かに、juliaのデータ型はこれだけではありませんが、通常のユーザーによって定義される最も一般的なデータ型です。

ドキュメントでこれを説明するための用語も変更する予定はありますか？さらに、このような章のタイトルを変更する予定はありますか？ そうでない場合は、 compositeとimmutable compositeまたはconst composite一番好きだと思います。 constはグローバル定数にも使用されるため、両方にconstまたはimmutableいずれかを選択しますが、 const少し優先します。短い。 少なくとも、compositeという単語はほとんどの初心者にはなじみがなく、ドキュメントを確認する必要があり、C名との類似性による誤った仮定を回避します。 constに関する誤った仮定は、C ++でそれに慣れている人は何も仮定しないことを知っているので、あまり起こりそうにありません。

また、不変性を示すために2つの単語を使用する利点により、必要が生じた場合に、将来のconst abstractとconst bitstype可能性が解放されます。

constレコードに不変が今意味することを意味させる場合、これは真実ではないかもしれません。 constレコードは、どのフィールドも変更できない参照タイプを記述します。 一方、現在の不変は値型です。

ええとああ。 immutableの価値は実装レベルで定義されていると思いました。ユーザーが考慮すべきことは、フィールドをリバウンドできないことだけです。 その場合、値を渡す（または渡さない）ことは純粋なABIの問題であり、コンパイラーは原則として、より効率的なものを自由に選択できる必要があります。 私には、不変のユーザーに表示されるセマンティクスは、タイプのすべてのフィールドにconstの現在のセマンティクスを適用することとまったく同じように見えます。

不変の意図されたユーザーレベルのセマンティクスについてまだ混乱していますか、それともここで実装の詳細について話しているのですか？

ナプルはどうですか？ もちろん、「名前付きタプル」の略です。

recordと一緒に行くこともできますよね？ たとえば、名前付きタプルは、Erlangのrecordです。 そして、データベースの世界でもそう思います。

しかし、ジュリアがCも知っている人々と重複している場合は、 structがより適切な変更です。

私は個人的にrecordような奇妙で不明瞭だと感じています。 データベースの世界では、レコードはテーブルの行です。 これは、Juliaタイプ（不変またはその他）と同じくらい一般的なものとの紛らわしい競合のようです。

このスレッドを読み直した後、私はtype compositeに傾いています。 それはジェフスの「一文ルール」を保持しており、それに対する反対票はそれほど多くありません。 この用語が他の言語ではあまり使用されていないということは、私の意見では問題ではありません。 そして、 compositeは、実際にそのために見つけることができる最も説明的な単語です。 これが、ドキュメントでこれらのものをcomposite typesと呼んでいる理由です。

Fortranから来て、私はまだキーワードtypeはちょうどいいと思います、
最小の賢明な変更はimmutable -> const typeです。

しかし、 type本当に行かなければならない場合、
compositeとconst compositeが次善の選択のようです。

immutable -> const type確かに実行可能のようです。同時に、混乱を避け、キーワードを削除し、言語を明確にします。

typeが使えないのは悲しいかもしれませんが、正直言って私が使いたいのはTypeです。 10回のうち9回、私の型変数は静的ディスパッチのパラメーターであり、動的型分析のDataType変数ではありません（生成された関数は例外です）。 inference.jlを書く人には当てはまりませんが、あなたがそうするのであれば、彼らは実際にはその言語の「ターゲットオーディエンス」ではありません。

関連する質問：トップレベルでtypeを使用することはまったく実行可能ですが、関数内（現在は常に無効です）で変数名にすることができますか？ またはさらに、型定義の構造はかなり具体的です...グローバル変数（または関数）でさえtypeバインドできるようにしながら、型定義を特定の構文として検出できますか？

つまり、型を定義するための構文を維持しながら、キーワードの動作を取り除くことができますか？

（おそらくimo）強いリスクが伴います：特異な辞書編集が気を散らすのは簡単になりすぎます。 そして、それらの欠けているマイクロ連続性は、コラボレーションと明確なコミュニケーションを容易にするために破壊的です。

@ c42f ：

不変の意図されたユーザーレベルのセマンティクスについてまだ混乱していますか、それともここで実装の詳細について話しているのですか？

いいえ、あなたは違います–私はずさんでした。 不変は実際には値型ではありませんが、可変は確かにそうではなく、Cと同じ用語を使用することはそれらがそうであることを示唆するかもしれないと感じました。

Cは値渡し言語であるというのが実際の状況であるため、Cのコンテキストでは、構造体を「値型」と呼ぶことが理にかなっているかどうかが明確でないことに気づきました。 したがって、間違いなく、データ型自体ではなく、受け渡しと割り当ての規則が異なります。

私は、この問題が開く変更を制定することに全面的に賛成です。 有用性は、候補用語の1つではなく1つを使用するという内臓の好みよりも重要です。

_しかし_

実際の状況はそのCなので

候補用語の中で、 structが私の最も嫌われている理由をうまく捉えています

私が販売しているストーリーは次のとおりです。「Cとjuliaの両方で、 structは、フィールド名の固定セットをさまざまなタイプの値にマップするデータ構造です。しかし、これらを渡すと、Cは渡されます。 -値によるとジュリアはパスバイシェアリングです。」

そのアカウントは、面倒ではなく、完全に正確です。 その中のすべてが正常にグーグルで検索できます。 PL理論家はそれについて不平を言うことはなく、非PL理論家はそれを聞いて何かを学ぶでしょう。

私はその話を買います。 疑問に思いますが、ここでPL理論家が不満を言う用語はありますか？ ジュリアは、PL理論家と非理論家の両方を満足させるニッチにぴったり合っていると思うので、ここで正確さと一般的な明快さのバランスをとることが重要だと思われます。

ええと、私は誰の口にも言葉を入れたくありません。 構造体が「値型」であるためにstructが混乱する可能性があるという考えに対処したかっただけです。

immutableは1語のキーワードのままにしておくべきだと思います。 const typeまたはconst structまたはimmutable struct好きではありません。 私はimmutableをよく使用しますが、他のほとんどすべてが1語であるのに、これらの宣言が2語になるのは非常に厄介だと思います。 タイピングの意味ではありません。それは本当の問題ではないからです。 しかし、「タグ」のように不変であるという意味では、それは二流のように感じます。

@TotalVerbそれは、という事実とあまり互換性がないと思います

type MyType
    const field::Int
end

まったく同じように動作する必要があります

immutable MyType
    field::Int
end

今します。

それを考えると、 const type （またはconst struct 、 const compositeなど）がショートカットとして各フィールドにconstをブロードキャストすることは便利なようです（ただし厳密には必要ありません）機能。 将来、コンパイラがどちらを入力したかさえわからないことを願っています（各フィールドの前にconst typeまたはconst -前者はパーサーによって後者に変換される可能性があります）。 その時点で、なぜimmutableですか？

「タグ」のように不変であると、二流の気分になります。

JeffとStefanを正しく理解していれば、そうです、 immutableは、型のフィールドが定数バインディングであることを示す単なるタグです。 定数（Cとは異なり、_really_定数）であると、コンパイラーが最適化を行うのに役立ちます。フィールド自体が定数またはプリミティブである場合（つまり、 isbits ）、さらに最適化を行うのに役立ちます。 これは知っておくと便利ですが、意味的には重要ではありません。 セマンティクスを現在の動作に関連付けると、将来その動作を改善することがより困難になる可能性があります。

しかし、重要な意味上の違いがあります。不変の型は値であるため、オブジェクトのIDはそのフィールドによって指定されていると安全に想定できます。 不変型のオブジェクトには、ユーザーの観点から、そのフィールドからアクセスできない特別な「識別機能」はありません。 一方、シングルトン以外の可変タイプのオブジェクトには、明らかにこの目に見えない「アイデンティティ」があります。 多くの不変型がボックス化されたオブジェクトとして格納され、したがって実際に内部でこの追加のIDを持っているという事実は、セマンティクスとは無関係です。

私の意見では、それは単なる_最適化_ではありません

immutable Complex{T} ... end

の代わりに

type Complex{T} ... end

ユーザーに見える動作の多くの側面が変化するためです： === 、デフォルトの== 、 objectid 、 hashなど。それを言うのは単に正しくありません。不変型は、可変型の機能のサブセットを提供します。 それどころか、それらが不変であるという事実自体が、不変型をより強力にすることを可能にする重要な保証を提供します。

コミュニティがconstとstructに落ち着く前に、 constantとstructure用にもう1つのプラグを作りたかっただけです。

1）実際の単語に3文字追加するだけです！
2） structが慣用的になっているという主張にもかかわらず
2a）Rから移行している人（私のように）は混乱するかもしれません
2b）プログラミングに不慣れな人（最も助けが必要な人）は混乱するかもしれません

ただ楽しみのために、構造体が混乱するかもしれない愚かな言葉：
不滅
閉塞症
ポスト構造主義
上部構造（ああ、マルクス）

およびconst：
コンスタンティノープル
星座
ボアコンストリクター
違憲

この種のマルチコンテキスト不変およびconstによって得られるPLの美しさ/力はありますか？不変は、解決された指示対象を介して/内部でブロードキャストせず（その性質を投影）、不変ではない埋め込み指示対象を介してconstブロードキャストを、副詞または動名詞であるかのように行いますか？

同じ質問、言い換えれば：

今のところ、グローバルスコープで変数を使用することには問題があり、回避するためのtrickは、単一のエントリを持つconstベクトルで変化する値をラップすることです。 その場合、 constはブロードキャストされません。 constのブロードキャストバージョンは、ベクトル内のエントリの値とベクトルに暗黙的に一定性を適用します。 同様に、他の種類の値をラップまたは囲む値を保持できるフィールドを持つ型宣言。 不変型は、そのフィールドの値に不変性を与えないようになりました（また、そのフィールドを介して間接的に到達する可能性のある値も与えられません）。 「このアイテム[またはこのタイプのアイテム]に割り当てられた値は、一度構築/初期化されても変更されない[変更は許可されない]」という意味のキーワードのブロードキャストバージョンに付属する優雅さと有用な容量があります。 。

即時（非ブロードキャスト）ソートは広く使用されており、Juliaで行うことの一部が、Juliaの事前コンパイルではるかに簡単になり、導入されたブロードキャスト可能なconstnessを使用したり、信頼したりできるようになると仮定すると、それを再生する必要があります。即時ソートでうまくいきます。 これが追加の_理論的なプログラミング言語の良さ_（表現のしやすさ、表現力など）をもたらす方法であるかどうか疑問に思います：ブロードキャストの恒常性は、参照型が埋め込まれている、および/または間接的に含まれている型の値を介してブロードキャストします（a）内部埋め込みまたはコンテナーを持たない値に到達すること、または（b）値に到達すること自体が（独立してまたはその他の方法で）非ブロードキャストの恒常性を持つタイプです。

これについてもっと考えてみると、私が本当に壊す価値があると思う唯一の変更はbitstype -> primitive 、主に何かをisbitsと呼ぶのがいかに面倒かということです。

この議論の本当のポイントであるtypeとimmutableについては、この時点で私が最も気に入っているオプションはまったく変更されていません。 型を構築するためのtypeは明確であり、不変の型を構築するためのimmutableは明確です。 しかし、私は私たちの最高の大君主が私たちに与えてくれたものは何でも喜んで受け入れます。私は暗黙のうちに、今後の言語に最適なものについての彼らの判断を信頼しているからです。

constやconstantではなくfixedを使用しない理由はありますか？ 少なくとも私には、はるかに明確な説明のようです。

@JeffreySarnoff参照（つまりポインタ）を取得できるものにconstことを暗示することconst type （ immutable ）のフィールドにバインドすると、この参照が他の場所に存在しないという証拠がないため、参照されるデータが一定であるという証拠がありません。

この振る舞いを変えることは、Julia言語にとって本当に根本的な変化になると思います。

@andyferrisその明確な答えをありがとう。

constやconstantではなくfixedを使用しない理由はありますか？ 少なくとも私には、はるかに明確な説明のようです。

constまたはconstantよりも優れたものがあるかどうか疑問に思っていました。これは、永続的なバインディングであり、バインドされたオブジェクト内のデータが変更できないことではないことを反映しています。 fixedはそれに向かっていくらか進んでいますが、他の言語ではそれを見ていません（また、他の言語でのJuliaのバインディング/共有セ​​マンティクスにも気づいていません）。

たぶんbindようなもの（例： bind x = 2 ）...シソーラスはglue示唆しています...これはかなり推測的になっています...

constをより正確なものに置き換えるというアイデアは魅力的です。 ただし、型宣言と個々の変数の代入の両方に適切に適用する必要があります。 fixed structはある程度意味がありますが、型宣言ではなく、構造体のフィールドが固定されています。 残念ながら、 bound struct （ tied struct ？）はかなり不明確に思えます。 何らかの理由で、 const型に適用すると、より明確に見えます。

型宣言と個々の変数の代入の両方に適切に適用する必要があります。

それを目指すのは生産的だと思います

type A
    const x::Int  # fixed, bind, bound, tied, glue
end

理にかなっています。 type 、 structなどの前にショートカットがあると、上記を意味するショートカットになります。

@generatedなど、物の性質を変える他の重要な装飾のように、これをマクロにすることは理にかなっています。 それはさらに別のキーワードを削除します...

type + composite > typeからの変更は素晴らしいと思います。

スレッドに新しいコメントを追加せずにGitHubの問題に投票できればいいのですが...私の投票はmutableとimmutable 、かなりきれいです。 structは使いすぎで、可変性の部分を強調していません。

PS：GitHubを知っている、または貢献して投票機能を追加できる人はいますか？ 「お問い合わせ」ページで聞いたのですが、メールが紛失した可能性があります。

最近、他の多くの言語のバックグラウンドを持つJuliaに切り替えたので、JuliaがCスタイルの命名を採用し、C / C ++の紛らわしいconst-nessの問題をすべて取り入れることを望んでいません。 代わりに、データ型宣言に、値型または共有参照型であるという意図を何らかの形で反映する概念を与えることは、単に可変性を参照するのではなく、私を大いに助けたでしょう。

Juliaでの私の最初の期待は、単純なtypeが、不変のCスタイルのstructまたはPythonオブジェクトと同様に動作することtypeは、Juliaが関数型プログラミングのスタイルと速度に重点を置いているように見えるためです。
type ...とimmutable...表現の非対称性にまだ混乱していますが、 DataTypeからtypeof(SomeType) DataTypeを取得するか、 'ビットタイプの実際の意味を取得します'、および単純なAlias = DataTypeステートメントの代わりにtypealiasキーワードの必要性。

したがって、私はdatatypeに投票します。これは、 typeof(SomeType) == DataTypeと一致し、 ::Type{}との苛立たしい類似性を壊します。 可変型をcomposite [datatype]装飾すると、基本的な「ビット型」と比較して、その特別でおそらくより高価な性質を強調することができます。

C / C ++の紛らわしいconst-nessの問題をすべて引き込む

このキーワードの名前を変更しても、それはできません。 これらの問題は、静的チェックとキャストに関係していますが、ここではまったく関係ありません。

単に可変性を参照するのではなく、値型または共有参照型であるという意図は、私を大いに助けてくれたでしょう。

私はこれを完全には理解していません。 オブジェクトが不変である場合、それが値によって渡されたのか参照によって渡されたのかを判断する方法はありません。それでは、値と参照の区別はどのように基本的なのでしょうか。

datatypeは悪い選択ではありません。 しかし、 datatypeとcomposite datatypeは、可変性の違いを伝える良い方法ではないと思います。

@ JeffBezanson 、Cのような定数を使用すると、Julia型がC / C ++と同じ動作をするという暗黙の期待を意味しました。構築後にのみ不変であり、キャストを通じて変更可能であり、関数の引数に対してまったく効果がない場合もあります。戻り値の型。 したがって、おそらくC / C ++を参照していないキーワードを選択する場合は、適切な選択です。したがって、 const structは使用しないでください。

「値と参照」について：不変型がメンバーを直接埋め込み、優れたコンパクトな高速アセンブラコードを生成する理由を理解するのにかなりの時間がかかりましたが、「type」にはオブジェクトへのすべての呼び出しが含まれていませんでした。 言い換えれば、スピードを目指すときに、なぜ私が通常NTupleを使用したいのかということです。 したがって、「不変」と「可変」を読むとき、Fortranの「パラメーター」としての意味を期待していましたが、実際のデータ型のレイアウトや実装の種類の変更も期待していませんでした。
おそらく、ほとんどの場合、Complexのような小さな複合型には「不変の値」のセマンティクスが必要ですが、配列などの大きなデータセットには「可変で参照/非コピー」が必要です。
その場合、根本的な意図はおそらく可変性ではなく、データのコピーを回避することです。

しかし、それは高速アセンブラコードを取得するためにJuliaの低レベルの機械を学んだときの私の経験でしたが、キーワードの命名にそれをより適切に反映する方法と、それを可変性だけで組み合わせたり表現したりする方法がわかりません。

私はあなたが@mjwから来ているところを知っています、私はそこに行ったことがありますが、C / C ++について知っていることをすべて学ばないほうがよいと思います。 ここで、不変であるのはconstであり、何かがスタックであるか動的に割り当てられるか、および参照または値で渡されるかどうかは自由に変更でき、コンパイラーの最適化の選択肢になります。 すべてが動的に割り当てられ、参照によって渡される言語を作成できます。これはJuliaのデフォルトの方法です（ボックス化された値の場合、タイプが不明な場合でも「共有による受け渡し」を実装します）。 あなた（そして私たちの残りの部分）は、最適化が現在実装されている場所であるため、小さな不変が非常に高速であることに気づきます。 これは、最適化を容易にするimmutableのセマンティクスの結果です。

しかし、実際には、大きな不変変数が参照によって渡され（おそらく、それが理にかなっている場合はスタックポインターによって渡されますが、 NTuple{1_000_000}をヒープ割り当てするのがおそらく最善です）、既知のサイズの小さな可変変数がスタック割り当てされることをお勧めします（繰り返しますが、可能な場合）。 場合によっては、ガベージコレクションでさえ静的に決定される可能性があり、たとえば、ヒープスペースをループ内で再利用できます。 私はこれらをエスケープ分析を必要とする将来の最適化の機会として描いています（そしてこれらはどれも言語のセマンティクスに影響を与えず、パフォーマンスだけに影響を与えます）。

私が言っているのは、キーワードは、数年で変更される実装の詳細（つまり、効率的な小さな不変と効率的な大きな不変）ではなく、10年か2年の間一定のままであるセマンティクスを反映する必要があるということです。

私は、JuliaタイプがC / C ++と同じ動作をするという暗黙の期待を意味しました

これは、正直に言うと、 const -> constantを検討するのに十分な理由かもしれません。 constは現時点で唯一の省略キーワードであり、とにかく奇妙なものになっていると思います。

単純なAlias = DataTypeステートメント。

これは理にかなっている場合は絶対に問題ないと確信していますが、 typealias RealMatrix{T<:Real} Matrix{T}などのより複雑なタイプの変更は許可されません。また、新しいType作成しない単純なバインディングです。 TypeVar s）。 逆に定義したい場合を除いて： RealMatrix = Matrix{T <: Real}そしてapplyがTypeVarに対して何をするかを一般化する（つまりTypeConstructor作る）...実際にはこれは興味深いアイデアです（ただし、構文の問題があるため、 typealiasが便利です...）。

@andyferris 、私はすでに「未学習」ですが、他の新しいユーザーにとっては、「コンパイルにもかかわらずジュリアがとても遅いのはなぜか」という段階を乗り越える方が簡単かもしれません。 これらの詳細のメンタルモデルの迅速な開発をサポートするキーワードを選択することは、コンピュータサイエンスのバックグラウンドがあまりない新規ユーザーにとって大きなセールスポイントになる可能性があります。 他の話し言葉の壁を避けるために、「単純な」キーワードも忘れないでください。

@mjwすばらしい、そして私はそのすべてに同意します。 :)

何を教えてください。GitHubの最高の機能であるリアクション絵文字を使用して、投票に最も近いものを試してみましょう。

ここでは、_順不同で_、最も支持されていると思われる提案を表にまとめました。 指定された絵文字を使用して反応し、その提案に投票します。 これには、デスクトップブラウザからGitHubにアクセスする必要があると思います。 AFAIKリアクション絵文字はモバイルインターフェースに実装されていません。 この投稿の右上隅にある顔をクリックして、絵文字のメニューにアクセスします。

| type | immutable | と反応する|
| ：-：| ：-：| ：-：|
| struct | const struct | 👍（+1）|
| mutable | immutable | 👎（-1）|
| type | immutable | 😄（笑）|
| composite | const composite | ：tada :(やったー）|
| datatype | const datatype | 😕（混乱）|
| type | const type | ❤️（ハート）|

もちろん、投票の失敗はnuple暗黙の投票に対応します。 ：ドヤ顔：

私は、このような論争の的となる決定を「民主的に」行うことの大ファンではないと言わざるを得ません。 コンセンサスなしで議論が行われた場合、私はBDFLの決定に従うだけです。

フェアポイント、@ TotalVerb。 前にも言ったように、彼らが最善だと思うものは何でも私たちに与える力を持っていれば、私はまったく問題ありません。 スレッドが少し曲がりくねっているように見え、投票に関する@juliohmのポイントは妥当なように思われるので、これを

個人的には、美的に2つの単語を使用するのは好きではないと思います（ const type ）。 また、意味的に少し不協和音を感じます。 const x = 1と言うとき。 xが一定であることを意味します。 const type; x; endと言うとき、このタイプのインスタンスは構築後に変更されないことを意味します。 ストレート補間から、何かが定数型であると言うことは、型自体が変更されないことを意味するように感じます（これはすでに当てはまります）。 参照：

type foo
end
const bar = foo

したがって、 barはconstであり、常にfooですが、それでもconst typeはありません。 const （バインディングに適用）の既存のセマンティクスに似ているように感じます。型の名前はすでにconstです。

簡潔で、意図されたセマンティクスを伝え、変数名として望ましいとは思われないキーワードはないと思います。 これらの目標に最も近いと思う用語は、3種類の宣言されたタイプのmutable datatype 、 immutable datatype 、およびabstract datatypeです。

typeとimmutableに加えて、追加の可変値タイプがあったらいいのにと思います。
問題のどこかでいくつかの議論を見てきましたが、基本的に現時点では、このようなシナリオを効率的に処理することは不可能です（何かを見逃した場合は修正してください）。

immutable T
    a::Int
    b::Float64
    ...
end

t = Vector{T}(10)
t[2].a = 5    # error here
# instead
c = t[2]
t[2] = T(5, c.b, ...)   # works  

コードは値型sizeof(T) * 10きちんとした配列を作成しますが、一部のフィールドを変更するには、 T(...)全体を再割り当てする必要があります。これは通常3〜5フィールドの長さです。
だから基本的に私の5セント：
type -GCが参照を収集
immutable -変更できない値（スタック割り当て）タイプ
mutable -特に配列で変更可能な値型

変更可能な値型

変更を許可することがオブジェクトのアイデンティティを与えるものであるため、これは達成不可能な目標だと思います。

おそらく、代わりにこのアプローチが必要です：＃11902

可変と不変を分離することを除いて、値と参照を分割する方が良いはずです。

abstract Node{T}
immutable Link{T} <: Node{T}
    value :: T
    next :: ref{Link{T}} # next :: Link{T} will be an error: Recursive type
end

値と参照を人為的に区別して言語を過度に複雑にする必要はありません。 可変型と不変型は意味的にはるかに単純です。 型が値型であるという事実は、単なる最適化です。

@Kenoは良い点を作ります

個人的には、美的に2つの単語（constタイプ）を持つのは好きではないと思います。 また、意味的に少し不協和音を感じます。 const x = 1と言うとき、xが定数であることを意味します。 const型と言うとき; バツ; つまり、このタイプのインスタンスは構築後に変更されないということです。 ストレート補間から、何かが定数型であると言うことは、型自体が変更されないことを意味するように感じます（これはすでに当てはまります）

前に述べたように、「正しい」セマンティクスはによって与えられると思います

type Complex{T}
    const re::T
    const im::T
end
z = Complex(1,2)

ここで、 z.reは、 const z.re = 1に似たものを入力したときと同じように動作するため、どのバインディングがconstあるかについて意味上の混乱はありません。

@JeffBezansonが述べているように、これは多数のフィールドにはあまり便利ではなく、現在の型の実装とは互換性がありません。 部分的に変更可能で、部分的に一定の構造体は、将来実装される場合とされない場合があります。 ただし、現在と将来の両方で意味のある構文があります。

<strong i="19">@const</strong> type Complex{T}
   re::T
   im::T
end

これが実装されている現在の方法では、マクロはASTでtypeからimmutableに変更できます。 将来的には、部分的に一定の構造体が実装されている場合でも、マクロは各フィールドにconstを追加することで、ASTに対して操作を実行できます。これは、フィールドバインディングであることは、すべての人にとって明らかです。一定です。 美的には、2つのキーワードを続けて使用するよりも優れています。関数に対して同様のことを行います（ @generated 、 @inline 、 @proagate_inboundsなど）。

@constは簡単に@immutableまたはそれに類似したものになり（ <strong i="31">@immutable</strong> type Val{T}; end OK、IMOを読み取ります）、マクロのアイデアはstruct 、 compositeと互換性があります、 等々。

@ be5invisはい、これは多くの言語で通常の方法です。たとえば、C＃にはstruct 、これはimmutableとしてさまざまな方法で動作します。コピーによって関数に渡され、明示的に割り当てられます。配列（ class | typeの場合のようにGC管理対象オブジェクトへの参照ではありません）。 ただし、これは_mutable_であり、配列内では単一のフィールドで変更できます。
immutable場合、2つのプロパティが混在していると私は信じています。

1. 不変性（適切な関数型プログラミングを行うため）
2. 下位レベルで値型として動作する

したがって、基本的には、プロパティ2のみの型の導入を望んでいます。これにより、既存のコードベースが中断されることはありません（ immutableが残ります）が、GCの関与を最小限に抑えて高速に何かを作成する場合は、価値があります。 。

@ johnmyleswhite ＃

@wgreenr前述のように、そして何度も議論されてきましたが、それは不可能です。 また、この号の議論とはあまり関係がありません。

何でも可能ですが、可変値型を導入することは非常に破壊的であり、非常に悪い考えです。 なぜそれが一見シンプルで魅力的なアイデアなのかは理解できますが、まったく異なる種類の新しいオブジェクトセマンティクスを追加し、タイプグラフを参照セマンティクスと値セマンティクスに分岐しても、言語は改善されません。 同じコードは未知のセマンティクスに応じて非常に異なることを行うため、それが達成することは、ジェネリックコードを安全に書くことを不可能にすることです。 ここに例を含む広範な議論があり

これが言及する価値があるかどうかはわかりません。 しかし、C / C ++では、「struct」はデータのレイアウトについても意味します。 一方、より良いメモリレイアウトを得るために、構造体メンバーを再配置することはしばしば価値があります。 構文の重大な変更を検討している場合は、「構造体」（順序付け-> C相互運用）と「不変」（何らかの方法で順序付けられる可能性がある）を何らかの方法で区別するメカニズムを用意する価値があります。

私はジュリアにかなり慣れていないので、何か明らかなことを見逃してしまったらごめんなさい。

私は個人的に名前について本当の好みはありません。 しかし、すでに「抽象的」が存在することを考えると、誰も「具体的」を提案していないように思われたことに驚いています。

さらに別の提案を追加するには、次のことが私には最善のようです。

• 使用structの代わりにimmutable 。

• struct!代わりにtypeます。 英語を話すとき、これは「可変構造体」と呼ばれるべきです。

  • （おそらく） struct!内のいくつかのフィールドをconstとしてマークできるようにします。

いくつかの正当化と考え：

1）明らかなことを見逃していない限り、 !関数を使用して不変型の値を操作することは絶対に避けてください。 それが間違っている場合（たとえば、不変型が可変型を参照し、 !の関数がそれを変更するという重要なケースがある場合）、この提案は適切ではない可能性があります。

2）不変型は、より多くの最適化の対象であり、プログラマーにとってより予測可能な動作をするため、一般的には可変型よりも優先されるべきだと思います。

3）これが機能するためには、ほとんどすべての場合に、不変型を少なくとも可変型と同じくらい効率的にするための最適化を実装することがおそらく前提条件です。 特に、コンパイラーは、参照によって大きな不変型を渡すことについて賢くなければなりません。

UPDATE：私recordの代わりにstructが、 record!あまりにも多くの動詞のようなものです。 頭に浮かぶ他のいくつかのオプション： newtype 、 typedef （Cプログラマーを10秒間混乱させる）、 composite 、または上記の誰かが提案したconcrete 。

v0.6の機能がフリーズする前に、このスペースで何かが発生する可能性はありますか？

（少なくとも公的には）決定が下されておらず、凍結からわずか10日しか離れていないことを考えると、おそらくそうではありません。

私はこれに注意深く従っていませんが、1つのコメントは、これが変更された場合、問題のあるファイル/行番号の適切な報告を最初に行うことを要求したいということです。 または少なくともモジュール。 0.5では、どのパッケージに@deprecate d _bindingがあるかを把握することさえ難しい場合があります。

外部参照https://github.com/JuliaLang/julia/pull/20418#issuecomment-277475415