Julia: 疯狂的主意：更改关键字“ type”

使单词type在其他情况下可用会很好。

我喜欢mutable的一致性。

如果这样做，则应尽快完成，以便可以将其包含在0.6

如果这将要发生，那么请使用每个人在思考之前认识的内容： struct

我还认为type有点尴尬。 当我向其他人解释时，我通常会说“像一个结构”，因此+1。

如果这将要发生，那么请使用每个人在思考之前认识的内容： struct

我以为immutable就像一个结构？

为mutable +1

immutable具有C结构的内存布局
type具有C结构的可变性

因此，struct与两者都相关。 我认为最好用mutable代替struct来阐明这一点。

任何变量都是可变的。 将该标签分配给一个普遍认可的名称（ struct ），对我来说几乎是清楚的。

对于来自Fortran的用户，关键字type已经很自然。
对于来自C的用户，关键字struct是很自然的。
对于经常使用immutable的用户，相反的关键字mutable是很自然的。

所以也许我们应该保持原样。

struct{mutable}
struct{immutable}

要么

record{mutable}
record{immutable}

如果需要更具描述性的形式。

如果我们使用struct那么不可变的语法可以是immutable struct （其中struct部分至少在最初是可选的）。

我怀疑Fortran程序员熟悉“结构”一词。

由于一致性， mutable +1。 如果选择了struct ，一致性是否会要求将不可变更改为const struct ？ ;）

我认为struct和immutable struct实际上会很好； struct是一个非常熟悉的术语，我们只需要添加一个新关键字。 即使不是严格要求，允许mutable struct也可能有意义。

我应该澄清一下，我认为struct作为名词是一种优势。 最好不要仅使用形容词来命名这些东西。

必须将struct到immutable struct会增加不必要的线噪声，甚至更多，因此习​​惯了不必键入此字符。

Otoh，我相信Fortran具有type关键字，该关键字的功能与我们的关键字非常相似。 但是，我并不反对更改此设置。

上面的@KristofferC是正确的：在解释这是什么时，我也发现自己在说“结构”。 即使在内部讨论中， type也是一个问题； 有人会说“假设x是一种类型”，并且不清楚它的意思是“用type关键字声明的东西”还是“类型”。

如果这些名称确实在表上（ s/type/new name/似乎有点令人讨厌），我建议我们可能要充分利用这一机会，使默认声明成为不可变的。
因此struct将替换immutable ，而mutable [struct]将替换type.

就像一个想法一样，可变的另一个可能术语也可能是Ref 。

另一个可能的名称是composite ，因为对此的通用CS术语是复合类型。 但是我仍然更喜欢mutable Foo和immutable Foo而不是mutable struct Foo和immutable struct Foo — struct （或composite或class或其他）似乎是多余的。

：+1：到名词

我一直喜欢朱莉娅中的type比struct （即使我的背景是_C_），因为朱莉娅的数据类型更强大，更微妙，我认为“结构”可能有点简单这个想法。 我还觉得，由于这是一种新语言，因此我们不应该受经验丰富的程序员习惯的约束-您还应该考虑“向以母语为母语的人解释这个词的最佳词汇是什么？”

在解释这是什么时，我也发现自己在说“结构”

想象一下，向struct T引入一个新来者，然后告诉他们T::DataType然后您可以使用::Type{T}进行调度，同时解释了Julia的“强大类型系统”。 我认为这只是在进一步推销。

成为名词是一个优势

：+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 vs type ，并且它只是引用，它允许在Julia绑定语义的上下文中实现可变性。

DataType包括所有名义类型： abstract ，位类型，不可变和可变结构。 因此，用DataType代替type并没有增加太多的清晰度。 我还从“新来者”场景中得出了不同的结论： ::Type和::DataType选择type T定义的事物的超集，因此让他们拥有不同的名字并不疯狂。 “ struct是Type ”比“ type是Type一种”更有意义。

我同意形容词在实践中可以充当名词。 可以说“这是一成不变的”。 我只是认为它们的描述性不足。 它并没有告诉您_is_是什么，它只是告诉您无论是什么，您都可以/不能对其进行变异。

我喜欢structure和mutable structure作为类型。 也许a = 1和mutable a = 1用于变量分配。 默认情况下不希望具有一致性，没有缩写和不变性的想法。

编辑：在默认情况下，在可变性中也许用constant代替const

或涉及较少关键字的版本将是struct与const struct 。 我认为，默认情况下将所有变量设置为const会造成破坏性。

我只是认为它们的描述性不足。 它并没有告诉您事物是什么，而是告诉您事物是什么，您可以/不能对其进行变异。

这是一个好点-但是我认为比“是结构还是位类型？”描述引用行为与“值”行为更重要和有趣。 （主要是因为bitstype不会经常出现-我创建的每个Julia类型都是一个结构）。 不变性只是绑定语义和值传递的结果。

为了完全消除对struct与bitstype我们还可以将@quinnj的想法包括在内

immutable 32 Int32 <: Integer

或者您可以将未修饰的字段作为位数

immutable Int32 <: Integer
   32
end

（通常在与命名字段混合时）对必要时插入填充也很有用。

然后，只能在值类型（当前是不可变的）和引用类型（当前是可变的）之间进行选择，但将来可能会使用const字段，这是不将其称为mutable另一个原因struct作为值引用类型会混淆Swift程序员...

自引入immutable以来， bitstype几乎消失了。 但是，与结构和位相比，还有更多需要区别的地方：存在抽象类型，元组（也是不可变的）以及将来可能不可变的记录。

我们最初选择immutable因为我们认为这将是最明显的区别功能：与其他对象不同，您无法对其进行修改。 实际上，它们并非总是按值传递； 不变性意味着您无法分辨差异。 有些immutable内联到数组和其他对象中，有些则没有。 不变性意味着区别对于纯朱莉娅代码不会造成任何问题； 仅当内存布局确实很重要（例如对于C互操作）时，这才成为问题。

实际上，它们总是不按值传递

好点子！ 不过，有计划要改变它，对吗？

我想我是说您将需要一组面向未来的关键字，以反映一些面向未来的概念，因为我们越来越接近1.0。 当内联不可变对象时，似乎是将它们重命名为对所产生的语义有所帮助的东西的合理时机（如果这些语义对FFI有帮助，那就更好了）。

我认为人们不会将新的具体类型定义关键字与abstract ， Tuple s和“ records”相混淆（如果您是用字段名表示类似元组的东西，我认为我也听说之前被称为“结构” ...）。

“按值传递”概念的真正目的是回答以下问题：当f(x)修改（在某种意义上） x会发生什么：是否会修改相同的x传入的呼叫者，还是仅在本地进行修改？ 朱莉娅从来没有，而且也永远不会有与这种行为不同的类型，参数或函数。 一切都是“共享”。 对我们而言，价值传递仅存在于ABI级别，但是该讨论仅属于手册的FFI部分。 我不确定我们是否会总是通过值传递或始终对其进行内联，因为对于大对象而言，这种类型的性能可能会更差。

无论如何，我确实认为immutable和mutable是关键字的可行选择。

的确，自引入不可变以来，bitstype几乎消失了

尽管个人通常不需要创建新的位类型，但是在原始级别上，现有位类型和常见不可变项之间的差异非常显着，因为它们的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中最常用的用户定义类型...”，如果“类型是一种类型”可能还不错吗？ 与“抽象类型”一样，在使用“复合类型”的通信中也应予以澄清。 关于线噪声，“常量类型”并不比“不变”差。

我不确定变量与类型对const含义的（轻微）区别。 -无论如何，类型和一成不变总是给我带来一点精神上的困扰。 很高兴在这里看到这个问题！

使用struct的主要问题是，人们自然会假设自己习惯于C / C ++，而这在Julia中不一定是正确的，例如，可变的复合类型不会按值存储在数组中，而一成不变的。

immutable比type更能代表什么范例？ 例如，通过实例化原始字段中更新了所需字段的新不可变对象，同时原子地“转换”多个字段的状态而无需同步原语。

为什么在定义时将类型分为两个不同的类别，而不是在派遣/使用时将其分为两个类别（更像是C ++中的const ）？ 通过仅使用type / struct / composite定义复合类型并引入Immutable{T}构造将可变变量提升为不可变变量，我们可以：

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

另外，是否可以在此处考虑更改abstract和bitstype ？ AFAICT中“抽象”的用法是形容词，而不是名词。 类型关键字之间应至少在语言上保持一致：所有名词，所有形容词等。 bitstype最好用bits或primitive 。

请不要将其变成一个开放的线程来讨论Julia关键字的拼写（或语义！）更改。 此时，该船已航行type _ immutable 。 这里提出的唯一问题是，我们是否可以使用type和immutable的拼写更好地反映它们的相似性。

我将继续支持mutable vs immutable ，或者将其保持原样，作为此时的两个最合理的选择。 其他任何事情都将毫无意义地造成破坏。

@andyferris我真的很喜欢这个主意； struct和const某种组合会很好。 如果采用这种方式，我也希望能够说出const struct或const type ，（1）避免在每个字段上写const ，（2 ），因此我们不必立即添加每字段不变性的新功能。 如果我们想添加该功能，则最好使用一致的词汇表。

在使用“复合类型”进行交流时，应阐明

我们最喜欢的命名技术之一是用一个句子向某人解释某件事，然后挑选出似乎最有效的一两个词。 所以对我来说，这将是对composite的投票。

为什么在定义时将类型分为两个不同的类别，而不是在派遣/使用时将其分为两个类别（更像C ++中的const）？

这很容易：提供全球保证。 在C ++中，如果有人对它进行非常量引用，则“ const”对象仍然可以更改。

另外，在这里可以考虑更改为abstract和bitstype吗？

提出建议。 至于bitstype ，该关键字很少使用，因此我不想盗用一个像bits这样的小字。

immutable -> const type对我来说似乎还可以。 如果我们确实要释放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的想法）。

正如Steve指出的那样，这将在整个社区中造成相当糟糕的代码流失。 而且好处是可疑的。

我肯定会看到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到组合的各个字段的想法可以在以后轻松实现，甚至更好，这是一个不间断的更改。

如果我们采用这种方式，我还希望能够说出const struct或const类型，（1）避免需要在每个字段上写const，（2）因此我们不必添加的新功能每场不变性。 如果我们想添加该功能，则最好使用一致的词汇表。

对我来说很有意义。

我查找了composite数据类型，发现至少Ada和Visual Basic也在其下包含了数组类型。 （否则，会随机发现：Haskell：列表和元组（但是需要定义）； Python：列表，元组，字典； 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 。 话说回来

我不会将有关实际命名的讨论与过渡所隐含的痛苦相混淆。

如果变更太痛苦，我会反对变更。 尽管pre1.0的更改是合理的，但将其与造成的任何干扰进行权衡是IMO的正确选择。

@stevengj对如何弃用提出了很好的建议，看起来@amitmurthy得出了相同的结论（将关键字保留的时间比我们平常多）。 虽然我们一直在使用这种语言一段时间，但仍处于初期阶段，我们不应该害怕进行更改。 这只是一个简单的搜索和替换。

我将继续投票给struct 。 我认为这是将引起大量嗡嗡声和抱怨的那些更改之一，但是实际上修复包/用户代码并不难……只要做到这一点，人们就会发现。

immutable -> const type似乎是阻力最小的路径，并且IMO绝对应该这样做。 我认为这可以解释得更好。

type -> composite比type更精确，但比struct不那么精确，而比struct少用行话新程序员）。 它通过Jeff的“写一个句子来向新手解释这句话”，并恢复了type关键字。不利的一面是，我认为composite不会以其他语言显示，因此我们一个人去。

type -> struct是最精确的，但可能structure比缩写更漂亮（我试图将缩写缩写为struct在该语言中的其他位置出现了空白-我认为eye()从英语角度来说是一个非常令人作呕的传统）。

如果更改type则bitstype -> primitive有意义。

@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少见（即使您在Google中“ record type ruby​​”还是“ struct type ruby​​”，或者用python或perl或某些替代词）其他非C语言）。 还有一个问题， record是一个非常有用的英语单词，保留为关键字将很可惜，而程序中的其他任何东西都可能不需要struct 。

struct是非常普遍的用法； 查看Rosettacode，它由以下人员使用：

algol，C，C＃，C ++，lisp，D，长生不老药，前进，前进，最大值，球拍，铁锈，seed7，swift，Visual Basic（ structure ）

record由以下人员使用：

ada，clojure，delphi，pascal，erlang，icon，modula-2，某些方案

record在较旧的语言中似乎是首选。 如今，随着函数式编程越来越流行，它倾向于引用结构化类型的记录。

有趣的是，尽管seed7使用new struct 。

有点遗憾地看到struct （有额外的三个字母来完成这个词真的那么糟糕吗？），使之成为至今已产生了语言function ，而不是func ， 等等。 任何人都不会拒绝某种语言，但是仍然...

structure实际上用于PL / I和Visual Basic。 VB也有structure immutable 。 但是struct非常普遍，我觉得它几乎已经成为一个新词。

我想知道这里是否还有母语的问题。 对我而言，在这种情况下非常习惯用struct来表达的是structure ，这听起来更奇怪。 由于相同的原因， func听起来很糟糕，而function自然。

struct不会由于在各种编程语言中的使用而成为一个独立的术语吗？ structure这个词（至少对我来说是德国人）更为抽象。 例如，该类型层次结构具有特定的“结构”。

func对我来说不是一个独立的术语，只是一个缩写。

func对我来说不是一个自成体系的术语，而只是一个缩写。

struct也不仅是缩写吗？ 它不是字面上的结构缩写，还是我只是误解了这个词？ 您比func更习惯

无论如何，我宁愿mutable ，所以我也不在乎_to__是结构还是结构。 mutable会避免一直为当前immutable编写const immutable 。

但是，即使最终结果是struct甚至strct或stct或strctr ，我也不太可能将Julia换成其他语言我的工作，所以... :)

抱歉，如果这在英语中没有意义：但是struct不是construct的缩写。 至少在德语中，使用Konstrukt这个词来描述什么是复合类型更有意义。

在英语中，无法分辨construct是名词还是动词，可能已排除了它在基于英语的编程语言中的使用：)在此，大写的德语用法很有帮助。

struct是它自己的单词，就像TV，ASAP和LOL是单词一样。 我很少听到人们说“结构”。 以我的经验，这个词是口头和书面上的“结构”。

顺便说一句：Matlab使用struct一词，如果有什么区别的话。

如上所述，C＃和Swift中的OTOH struct对应于值类型（与class ）。 因此，对可变类型和不可变类型使用相似的术语并不会真正帮助熟悉这些语言的人。 不确定这是否是决定性的点...。

mutable / immutable听起来是最明确的选择，对于新手来说应该很明显。

鉴于大量使用struct的不同语言，我认为使用该名称不需要具有相同的语义。

我最喜欢type和const type ，但这并不能释放type关键字。 由于我不知道type的计划是什么，所以我不知道成本是多少。

但是由于type部分已经隐含在abstract ，所以也许自己单独使用mutable和immutable是最有意义的。 而且它的键入要少一些immutable struct和一个小的更改（类型->可变）。

这个词的结构（至少对我来说是德国人）更为抽象。

当我们在讨论语言时，每个人都低估了struct的缩写量。 它是“数据结构”的缩写。 同样，我会说type是“数据类型”的缩写。 我敢说数组或缓冲区也是数据结构，就像链表一样，等等，但是struct最早的根源是最早的常见数据结构之一，在计算中它已经有了它本身具有更具体的含义（因此，对于母语为英语的程序员而言，它听起来不像structure那样抽象）。

-1至struct 。 除非与C程序员交谈，否则我不会使用该术语来解释类型定义是什么，然后仅提及布局是兼容的并比较/对比其属性。

我觉得正是这条路大约struct 。 我觉得我们会在没有特定原因的情况下为Julia引入一个新术语。

-1至const 。 C朝着拥有绝对最少的关键字的方向发展，现在我们被许多具有上下文敏感含义的关键字所困扰。 我真的不认为const是这些类型的关键属性，而是它们是值类型（与引用类型相对）。

Jeff在上面（非常友好地）向我解释，从语义上讲，我们不在乎事物是值还是引用还是其他东西-这些是实现细节，而不是语义，在未来的黄金时代_我们将不在乎。 事情以编译器想要的任何方式“通过共享”（必要时带有一些FFI保证）。 在过去的几天中，我已经称其为“按魔术分享”，我觉得这对我来说是一个启示，它减轻了我的精神压力，（理想情况下）我不需要思考（ @vtjnash，您已经了解了我如何处理值和引用，以及如何在其他程序包和线程中通过编译器和GC等实现这些值和引用）。

绑定可以更改或保持不变（我们使用const但constant也很可爱）。 同样，复合数据类型内部的字段绑定可以更改，也可以是恒定的。 这就是为什么我建议更早地将const显式附加到每个字段的原因-它使语义清晰（至少对我来说）。

IMO，我们不需要使用诸如“可变性”和“不可变”之类的花哨的词来谈论这些东西。 某些东西可以反弹到新物体上，否则它是恒定不变的。 完全从我们关于Julia的论述（不仅是代码）中消除对struct和immutable类的复杂英语单词的需求（不仅是代码），应该被视为一件好事（甚至是目标）。

我也觉得“结构”是它自己的词（意思是在C语言中的含义），而“结构”可能是“数据结构” –因为如果您要表示记录类型，您会说“结构”。 但是我在这里显示我的C根。

这也很常见。 defstruct 。

可能比这里的大多数其他要点琐碎，但只要我们骑自行车出行：大声说出来时，短语immutable object和a mutable object听起来很讨厌。 这将使与Julia的类型系统的对话比实际需要的困难。 编辑：似乎已经在此线程中提出来了。

+1至type -> struct和immutable -> const struct 。 我认为我从未见过有人对此感到困惑，尤其是经过粗略的解释之后。

对于v0.6，替换type是现实的，而对于v0.8是不现实的。 我们应该这样做。 这是一个使人变得更加顺畅和提高朱莉娅天生的才能的机会，以实现清晰的沟通和快速的表达。 类型非常适合创建能够正常工作的软件。 更好地对典型事物进行命名会产生强烈的共鸣，并为朱莉娅带来更富传奇色彩的未来。

我建议不使用struct 。 在C语言中，结构是用于类型固定字段的固定序列的语法容器。 朱莉娅不是C，而将C主义带入朱利安话语中，将朱莉娅的表位性质推到认真讨论最佳使用方式和概念化朱莉娅方面的更好方法之外。

同样，“不变”和“可变”在视觉上也太协调了。 我们可以做得更好。

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@JeffreySarnoff顺便说一句，根据社区标准，最好将Julia称为“它”。 只是以为我会提到它。 🙂

@ararslan有关Julia的社区标准指南似乎已更改，现在避开了文学代词的应用。 谢谢您引起我的注意。 ：蟋蟀：

使用女性代词本身并不是一件坏事（在许多语言中都是不可避免的），但是似乎很多人发现从使用“她”一词过渡到谈论朱莉娅是一个炙手可热的约会是不可抗拒的，所以似乎最好尽可能完全避免诱惑。

谢谢

2016年11月3日，星期四，下午4：29，Stefan Karpinski [email protected]
写道：

使用女性代词本身并不坏（在许多情况下是不可避免的）
语言），但似乎很多人都觉得无法避免使用
“她”一词是指朱莉娅是一个热门约会，所以似乎最好
尽可能完全避免诱惑。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
。

关于眼前的问题，我个人还不确定我认为最好的改变。 但是，谈论Julia令人惊叹的_type_系统，然后指定用于构造类型的关键字实际上是struct而不是type ，这对我来说似乎很奇怪。 我认为这可能会鼓励人们将类型作为结构来谈论，最终导致用于描述Julia的语言发生变化，例如讨论Julia令人惊叹的_struct_系统。

用于构造类型的关键字实际上是struct而不是type

但是关键字实际上并不是关于构造类型的，例如，表达式Tuple{Int}也会构造类型。 如果当前用type定义的东西总是被称为struct s，那会很好，因为那样的话，对于Real是如何类型，以及Union{Int8,Int16}是一种类型，依此类推。

是的，我正在编辑我以前的笔记，并且刚才已经写了。 这将是
普遍有害于朱莉娅和
表达能力和简洁性的未来发展。 门应该是
打开以使朱莉娅的类型系统的考虑合法
在C结构上搭建脚手架，战争就败了。

2016年11月3日，星期四，下午4：38，Alex Arslan [email protected]
写道：

关于眼前的问题，我个人还不确定
会考虑最好的改变。 但是我说这似乎很奇怪
Julia的惊人的_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 ，每个人都不会认为所有julia类型都是结构。

好的，很好。

而Union {Int8，Int16}是一种类型

啊。 我忘记了Union也存在。 国际海事组织，这使对struct （ Struct ？）的论点更具说服力。 仍然不喜欢mutable和immutable 。

我发现struct很明显，并且真的相信随身携带Julia会随着时间的推移将不断发展的时代精神推向下方。 原理是运动位的显示与计算可能的表达之间的对立，即更高阶的融合和更深的格式塔。 使用struct不会导致每个人都想到结构的类型。 ...让我过分夸张...

我不能说写关于爱因斯坦作为专利书记的文章会减少对他的贡献的赞赏。 因此，在提到阿尔伯特·爱因斯坦（Albert Einstein）的过程中，他淡化了他作为专利书记员的时间的重要性，因此，在未来的对话中，不止几个学生会对此有所感悟。 一个东西是so并不能确保它搬到新学校后的行为仅so 。

如果有使用_struct_的令人信服的情况，则应该为以下一种情况提供更好的情况：

structure是零件的有意义的相互关系，是一个有根据的组合
construct是有用的结余结构，一种增值设计

一个不变的structure是一种持久成分
可变的structure是不确定的
不可变的construct是确定的结果
可变的construct是上下文的故意约束

我们既需要“在位和通过门的位”的说话方式，也需要“数据结构揭示本体信息”，并且可以将其用作变换修饰语。 作为CS人才的社区参与者和大多数在其他领域进行编程的大多数领域专家都对字节，内存，逻辑，指令操作等有透彻的了解。使欲望，创造力，可能性和想象力成为现实的软件的另一种方法是非常值得的工作-共享较少。 关于术语命名的任何决定都应鼓励这种说法。

那么class和immutable呢？

我知道来自Delphi的课程，并认为在这里是不可能的，但是在具有多种方法的尼斯语言中，它用作关键字（ link ）。 而且-如果我正确阅读了手册-也在Haskell和Dylan中。 它通过了“类是一种类型”测试，但仍然很模糊（今天称为“类型”），这是我喜欢的。 在15:00-15:20分钟的“数组和迭代概述”视频中，Tim Holy（偶然地）说了“类”，一个不重要的细节，但也许表明，在Julia上下文中，类不会是完全陌生的。

否则， reftype和immutable吗？ 最初评论中提到了reftype术语，此后一直被忽略。 为什么？ 对我来说，这听起来很不错，可以释放类型并传送参考含义。

（我不明白'new'关键字的目的。不能将'new'保留在所有行中而不做任何更改？'value'和'record'术语将成为关键字，并替换当前使用的'immutable'和“类型”，对不对？）

@swissr这两种类型之间的唯一区别（大多数用户应该注意）是，一种类型的字段可以更改，而另一种类型的字段不能更改。 如果它们的名称表明它们唯一的语义区别，那将是合乎逻辑的。 （如前所述，使用值和引用的实现是不固定的-例如，经过改进的编译器可能会自动通过引用传递大的isbits类型作为优化，相反，在某些情况下，小的可变项可能会移到堆栈中）。

关于type与struct ，我确实看到我可以使用abstract ， Union{} ， typealias等来制作抽象数据类型（在Tuple{}的情况下，可以争论是新类型还是仅是参数化类型），但实际上唯一的用户定义的具体类型是由bitstype ， type immutable 。 这些语法与抽象定义毫无疑问，因为它们以某种方式定义了其中包含的数据，而抽象则没有。 将immutable更改const type似乎使我明白了这种情况。

当我们有机会创建以外行的术语进行讨论的编程语言时，我确实担心语言并传播技术单词struct ，唯一的原因是传统。 我认为这无济于事的一个例子是当我创建一个包装类型如Symmetric{Matrix{T}} -我不希望我的讨论成为这样，“我仅用一个字段创建了此struct我可以说“我为Symmetric制作了一个type Matrix ”（请注意，该句子的一半是实际语法）。 一个“包装器结构”？ 听起来有点愚蠢-谁在一个领域造出一个结构？ 那么，没有字段的单例呢？ types和immutables的相当大的一部分不是为了创建任何（非平凡的）数据结构而定义的，而是明确的目的是使用功能强大的类型和分派系统以及包装器和单例。 海事组织这是朱莉娅最有趣，最有力和最富表现力的一面（结合事实是“快”）。

我觉得struct的全部功能只会对经验丰富的模板C ++元编程人员立即显现，他们知道他们可以使用结构实现特征等，这有点可耻。

“种类”在类型论中具有相当具体的技术含义。

如果目标/优势是释放type那么如何：

const datatype  # immutable
datatype        # type

它们是具体类型，因此它们可能包含数据，这是构造DataType一种（许多方式）。

“种类”在类型论中具有相当具体的技术含义。

Wiki的介绍听起来像Type{} （接受DataType和TypeConstructor ， Union等）（编辑：不是，我认为这样的更改值得破坏）

kind在这里不是正确的词。

我觉得最好的方法通常是学习一个领域的
标准词汇表，而不是尝试用您替换的词汇表
猜测会更容易。

该决定不影响非正式演讲。 您仍然可以明智地说：“我
定义类型”。使用更具体的关键字只会使
您需要精确。

公平点，杰夫。 请注意，我认为const struct和struct比immutable vs type有所改善（但这并不意味着我们不应该搜索更好的东西）。

当您认为struct是将其更多地看作是结构还是构造时，两者都不是？

@andyferris我的'class'和'reftype'评论并不意味着我也不会喜欢'const type'或不支持const struct和struct会有所改善。 这是另一种试图避免“ const”，保留“ immutable”并保留“ struct”的可能术语的尝试（已经意识到所提到的实现，但是认为如果在80％以上的情况下是正确的，那是可以的） 。

fieldtype （或fieldstype ）怎么样？ 它与bitstype平行，并与fieldnames() 。

格伦
我喜欢真实感。 使用fieldstype是更好的选择，因为使用复数形式可以使某些事物为单数或复数是适当的。
-杰弗里

class可能还可以； 我们最初拒绝了它，因为它与基于类的OO以及对象内部的方法相关联。 我会说struct更准确。

我不认为struct是任何东西的简称； 这就是这些数据结构的名称。 有点有趣的是，lisp有cons ，它最初可能是construct的缩写，但是人们很快就忘记了这一点，只是开始谈论“ cons cells”。

我认为我们应该继续拒绝class 。 使用该术语会引起一大堆OOP期望，这与Julia的风格背道而驰。

我不认为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是一种值类型。

请参阅https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059和以下评论，以获取对record一些讨论。

@vtjnash很好，但是它类似于现在发生的情况，其中immutable如果包含任何引用，则成为“引用”类型。

我认为record不太常见的事实是可以的，因为它既是名词又是动词，所以它是一个有用的词，这会带来更多问题。

nuple怎么样？ 当然，“命名元组”的缩写。

我喜欢上面的建议

const datatype  # immutable
datatype        # type

到目前为止最好。 它避免了带历史包bag的陈词滥调，对我而言似乎完全清楚。 当然，它不是julia中唯一的数据类型，但它是普通用户定义的最常见的数据类型。

是否有计划更改文档中用于解释此内容的术语，更重要的是更改此类章节的标题？ 如果没有，我想我最喜欢composite和immutable composite或const composite 。 由于const也用于全局常量，因此我会为这两个都选择const或immutable ，略微选择const因为较短。 至少对于大多数新手来说，“复合”一词不会看起来很熟悉，迫使他们仔细阅读文档并避免由于与C名称相似而产生的错误假设。 关于const错误假设似乎不太可能，因为习惯于C ++的任何人都不会假设任何东西。

同样，使用两个词表示不变性的优点还可以释放将来可能出现的const abstract和const bitstype 。

如果我们让const record表示现在不变的含义，那可能就不正确了。 const记录将描述一个引用类型，该字段不能更改。 而当前不变量是一个值类型。

哦哦我认为immutable的价值与否是在实现级别定义的，所有用户要考虑的是字段不能反弹。 因此，按值传递（或不传递值）是一个纯粹的ABI问题，原则上编译器应可以自由选择效率更高的选项。 在我看来，不可变的用户可见语义似乎完全等同于将const的当前语义应用于类型的所有字段。

我是否对不可变的预期用户级语义感到困惑，还是在这里谈论实现细节？

核仁怎么样？ 当然，“命名元组”的缩写。

也可以选择record吧？ 例如，一个命名的元组就是Erlang中的record 。 而且我认为在数据库世界中也是如此。

但是，如果Julia与那些也知道C人更多地重叠，则struct是更合适的更改。

我个人认为record有点奇怪和不清楚。 在数据库世界中，一条记录就是表中的一行。 与一般的Julia类型（不可变或其他）一样，这似乎是一个令人困惑的冲突。

重新读取该线程后，我倾向于type composite type 。 它持有杰夫斯的“一句法则”，但没有多少人反对。 我认为，该术语在其他语言中使用不多，并不是一个问题。 composite实际上是人们可以找到的最具描述性的词。 这就是文档将这些内容称为composite types 。

来自Fortran，我仍然认为关键字type很好，
并且最小的明智更改将是immutable -> const type 。

但是如果真的要走type ，
composite和const composite似乎是下一个最佳选择。

immutable -> const type当然似乎可行：它可以同时避免中断，删除关键字并增加语言的清晰度。

不能使用type可能很可悲，但是老实说我想使用的是Type 。 十个我的类型变量中有九个是用于静态调度的参数，而不是用于动态类型分析的DataType变量（生成函数除外）。 对于编写inference.jl的人而言，并非如此，但如果您愿意的话，他们并不是该语言的“目标受众”。

相关问题：在顶层使用type是否可行，但是在函数内部（当前始终无效）使用它作为变量名？ 甚至更进一步，类型定义的结构是非常特定的...我们可以将类型定义检测为特定的语法，同时甚至允许将全局变量（或函数）绑定到type吗？

即我们可以在保留用于定义类型的语法的同时摆脱关键字行为吗？

（不太可能是imo）存在很大的风险：特有的词典编排太容易分散注意力了。 那些缺少的微连续性会破坏协作和清晰的沟通。

@ c42f ：

我仍然对预期的不可变的用户级语义感到困惑，还是在这里谈论实现细节？

不，您不是–我很马虎。 不可变不是真正的值类型，但可变的肯定不是，我觉得使用与C相同的术语可能表明它们是值。

我只是意识到在C的上下文中，将结构称为“值类型”是否有意义尚不清楚，因为实际情况是C是一种按值传递语言。 因此可以说，传递和分配约定是不同的，而不是数据类型本身。

我完全赞成实施此问题打开的更改。 实用性胜过任何内在的偏爱，即使用一个而不是另一个候选术语。

_虽然_

因为实际情况是C

很好地说明了为什么在候选词中struct是我最不喜欢的

这是我卖的故事：“在C和julia中， struct是一个数据结构，它将一组固定的字段名称映射为各种类型的值。但是当您将它们传递给C时，C就是传递价值评估和茱莉亚的分享。”

该账目既繁琐又完全准确。 其中的所有内容都可以成功搜索到。 没有PL理论家会抱怨它，非PL理论家会通过听它学到一些东西。

我买那个故事。 虽然我不知道，但这里有没有提到PL理论家会抱怨的术语？ 我喜欢认为Julia适合于既能满足PL理论家又能满足非理论家的利基市场，因此在这里要在正确性和总体清晰度之间取得平衡似乎至关重要。

好吧，我不想在任何人的嘴里说些什么； 我只是想解决一下这样的想法，由于结构是“值类型”， struct可能会造成混淆。

我认为immutable应该仍然是一个单字关键字。 我不喜欢const type或const struct或immutable struct 。 我经常使用immutable并且我认为这些声明是两个单词，而其他所有内容都是一个单词，这确实很尴尬。 不是打字的意思，因为这不是真正的问题。 但是从某种意义上说，拥有像“标签”一样的不变性使其具有第二流的感觉。

@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只是一个标记，表明类型的字段是常量绑定。 常量（_really_常量，不像C）可以帮助编译器进行优化，如果字段本身是递归常量或原语（即isbits ），则可以帮助其进行更多优化。 这是众所周知的，但在语义上并不重要。 将语义与当前行为联系起来可能会使将来更难以改善该行为。

但是存在一个重要的语义差异：不可变类型是值，因此可以安全地假定对象的标识由其字段指定。 从用户的角度来看，不可变类型的对象没有从其字段不可访问的特殊“识别特征”。 另一方面，任何非单可变类型的对象显然都具有这种不可见的“身份”。 许多不可变类型存储为盒装对象，因此实际上在内部确实具有这种额外的标识这一事实与语义无关。

我认为，这不仅是一项“优化”

immutable Complex{T} ... end

代替

type Complex{T} ... end

因为用户可见的行为的许多方面都发生了变化： === ，默认== ， objectid ， hash等，所以说这是不正确的不可变类型提供可变类型功能的子集； 相反，它们是不可变的这一事实提供了重要的保证，可以使不可变的类型更强大。

在社区适应const和struct ，我只是想再为constant和structure做一个插件。

1）实际单词只需要三个字母！
2）尽管声称struct已成为惯用语
2a）从R迁移的某人（像我一样）可能会感到困惑
2b）刚接触编程的人（需要最大帮助的人）可能会感到困惑

只是为了好玩，可将struct的愚蠢单词混为一谈：
坚不可摧
阻碍主义
后结构主义
上层建筑（哦，马克思）

和const：
君士坦丁堡
星座
蟒蛇
违宪的

是否存在通过多上下文不可变和此类const获得的PL美感/能力：不可变从不通过/在解析的对象内部广播（投射其性质），以及通过不可变的嵌入式对象（例如它是副词或动名词）进行const广播？

换句话说，同样的问题：

目前，在全局范围内使用变量是有问题的，要解决的trick是使用单个条目将变化的值包装在const向量中。 在这种情况下，不会广播const 。 const的广播版本将对向量以及向量中的条目的值隐含恒定性。 同样，类型声明的字段可能包含用于包装或封装其他类型值的值。 现在，不可变类型不会为其字段的值赋予不可更改性（并且不会通过其字段间接获得任何值）。 关键字的广播版本带有afaik的优雅和有用的功能，它表示“一旦构造/初始化了归属于此项目（或此类型项目）的值，就不会更改[不允许更改]” 。

立即（非广播）排序已得到广泛使用，并且假设人们对Julia的处理变得容易得多，因为Julia的预编译使其可以更好/更快/更简单地使用或依赖于可广播常量的介绍，然后需要玩可以立即排序。 我想知道这是否会带来额外的“理论编程语言”（表达轻松，表达能力……）：广播常数通过具有嵌入式引用类型和/或具有？间接包含类型的类型的值进行广播，直到（a）达到一个没有内部嵌入或容器的值，或（b）达到一个值本身（独立地或以其他方式）具有非广播常量的类型。

对此进行更多思考，我真正认为值得进行更改的唯一更改是bitstype -> primitive ，主要是因为调用isbits太烦人

至于本次讨论的真正意义， type和immutable ，在这一点上，我发现我最喜欢的选项根本没有任何改变。 type构造一个类型是明确的， immutable构造一个不变类型是明确的。 但是，我会很乐意接受我们最高的霸主给我们的一切，因为我暗中相信他们对哪种语言最适合未来的判断。

有什么理由不使用固定的而不是const或常量吗？ 至少对我来说，这似乎是一个更加清晰的描述。

@JeffreySarnoff很难暗示您可以获取引用（即指针）的事物具有const本质。 Julia的“共享”语义意味着，编译器无法证明是真正不变的任何东西都必须是引用类型。 当您将这样的引用绑定到const type （ immutable ）的字段时，没有证据表明此引用在其他地方不存在，因此也没有证据证明所引用的数据是恒定的。

我认为改变这种行为将是对Julia语言的真正根本改变。

@andyferris谢谢您的明确回答。

有什么理由不使用fixed而不是const或constant吗？ 至少对我来说，这似乎是一个更加清晰的描述。

我一直想知道是否有比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 ++常数性问题。 相反，给数据类型声明一个概念以某种方式反映作为值类型或共享引用类型的意图会极大地帮助我，而不是简单地提到可变性。

我最初对Julia的期望是使一个简单的type的行为类似于不可变的C风格struct或Python对象，因为Julia看起来与功能编程风格和速度有关。
我仍然对type ...和immutable...措词不对称感到困惑，但是从typeof(SomeType)或DataType ”，以及使用typealias关键字而不是简单的Alias = DataType语句的必要性。

因此，我将投票给datatype ，这将与typeof(SomeType) == DataType ，并且会破坏与::Type{}的令人讨厌的相似性。 与基本的“位类型”相比，用composite [datatype]装饰可变类型可能会突出其特殊性，甚至可能更昂贵。

拉入所有令人困惑的C / C ++的一致性问题

重命名此关键字不会这样做。 这些问题与静态检查和强制转换有关，此处完全不涉及。

成为值类型或共享引用类型的意图将极大地帮助我，而不是简单地提到可变性

我不完全明白这一点。 如果对象是不可变的，则无法判断是值传递还是引用传递了对象，那么值/引用的区别怎么能成为基础？

datatype不错。 但是我不认为datatype与composite datatype是传达可变性区别的好方法。

@JeffBezanson ，具有类似C的const struct 。

关于“值与引用”：我花了相当长的时间才能理解为什么不可变类型直接将成员嵌入并生成美观而紧凑的快速汇编代码，但是“类型”却没有，并且仍然包含对对象的所有调用。 换句话说，为什么我通常想在速度上使用NTuple。 因此，在阅读“不可变”和“可变”时，我期望在Fortran中将其作为“参数”的含义，而不是实际数据类型的布局或实现类型的更改。
大概大多数时候，人们可能希望对小型复合类型（如Complex）具有“不变值”语义，而对大型数据集（如数组等）具有“可变和引用/非复制”语义。
然后，潜在的目的可能不是可变性，而是避免复制数据。

但是，这是我在学习Julia低级机器以获取快速汇编代码时的经验，但是我不知道如何在命名关键字时更好地体现这一点，以及如何将其与可变性结合或表达出来。

我从@mjw那里获得您的来信，我去过那里，但是我认为您最好不学习有关C / C ++的所有知识。 在这里， const -ness是不可变的，某些内容是堆栈还是动态分配的，以及它是通过引用还是通过值传递的，可以自由更改，并且将是编译器的优化选择。 您可以创建一种语言，其中所有内容均通过引用进行动态分配和传递，这是Julia的默认方式（对于带框值-即使类型未知，它也实现“通过共享传递”）。 您（以及我们其他人）注意到，小型不可变对象的运行速度如此之快，因为这是当前实现优化的地方。 这是immutable语义使优化更容易的结果。

但是，实际上，我更喜欢通过引用传递大的不可变对象（也许是通过堆栈指针，在这里有意义，但最好是堆分配NTuple{1_000_000} ），并且将已知大小的小可变变量分配给堆栈（再次，如果可能）。 在某些情况下，甚至可以静态确定垃圾回收，例如，允许在循环内部重用堆空间。 我将它们描述为需要逸出分析的未来优化机会（这些都不影响语言的语义，仅影响性能）。

我想我想说的是，关键字需要反映的语义将保持一两年之久，而不是会在几年内改变的实现细节（即有效的小可变变量和有效的大不可变变量）。

我的意思是可能暗示对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关于投票的观点似乎很合理，所以我认为我可以

就个人而言，我认为我不喜欢从美学角度讲两个词（ const type ）。 在语义上也有些不和谐。 当我们说const x = 1 。 我们的意思是x是常数。 当我们说const type; x; end我们的意思是这种类型的实例在构造后不会改变。 从直接插值中，感觉好像是某种常量类型意味着该类型本身不会改变（现在已经是这种情况了）。 也可以看看：

type foo
end
const bar = foo

因此bar是const并且始终是foo，但不是const type 。 感觉就像const的现有语义（应用于绑定）一样，类型的名称已经是const了。

我怀疑没有简洁明了，传达预期语义且不太希望用作变量名的关键字。 我觉得最接近这些目标的术语是三种声明类型的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很好

就个人而言，我认为我不喜欢在美学上使用两个词（const类型）。 在语义上也有些不和谐。 当我们说const x = 1时，我们的意思是x是常数。 当我们说const type时； X; 最后，我们的意思是这种类型的实例在构造后不会改变。 从直接插值中，感觉好像是某种常量类型意味着该类型本身不会改变（现在已经是这种情况了）

如前所述，我认为“正确”的语义是由

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进行操作，并且所有人都会清楚这是字段绑定这是恒定的。 从美学上讲，它比连续两个关键字要好-我们对函数执行类似的操作（ @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的情况下，混合了以下两种属性：

1. 不变性（用于进行适当的功能编程）
2. 表现为较低级别的值类型

因此，基本上，我很乐意看到仅带有属性2的类型的介绍。这不会破坏现有的代码库（仍然保留immutable ），但是对于那些只花很少的GC就能快速编写某些东西的人来说，那将是很有价值的。

@johnmyleswhite谢谢你＃11902，仍然相信它不应该那么丑

@wgreenr如前所述，并且已经讨论了很多次，这是不可能的。 它也与本期的讨论并没有真正的关系。

除了引入可变的值类型外，任何可能的事情都将带来极大的破坏性，并且是一个非常糟糕的主意。 我可以理解为什么它是一个看似简单且吸引人的想法，但是添加一种全新的，完全不同的对象语义并将类型图分成引用和值语义两类并不能使语言变得更好。 它会完成的工作是使无法安全地编写通用代码，因为相同的代码根据未知的语义会做非常不同的事情。 还有用实例进行了广泛讨论这里。 ＃11902的重点是在不破坏事物的情况下恢复可变值类型的好处。

我不确定这是否值得一提； 但是在C / C ++中，“结构”还暗示了有关数据布局的某些信息。 另一方面，通常值得重新安排结构成员以获得更好的内存布局。 如果您正在考虑对语法进行重大更改，可能值得拥有一种以某种方式区分“结构”（有序-> C互操作）和“不可变”（可能以任何方式进行排序）的机制。

我对朱莉娅（Julia）相当陌生，所以如果我错过明显的事情，我感到抱歉。

我个人没有名字的真实偏好。 但是，令我惊讶的是，似乎没有人建议“具体”，因为已经存在“抽象”。

再加上一点建议，以下对我来说似乎最好：

• 使用struct代替immutable 。

• 使用struct!代替type 。 说英语时，应将其称为“可变结构”。

  • （也许）允许将struct!内的某些字段标记为const 。

一些理由和想法：

1）除非我错过了显而易见的事情，否则您永远都不想使用带有!的函数来操纵不可变类型的值。 如果那是错误的（例如，在重要的情况下，不可变类型引用可变的类型，并且带有!的函数对其进行了更改），则此建议可能不是一个好建议。

2）我认为不可变类型通常比可变类型更可取，因为它们会受到更多的优化，并且对于程序员而言具有更可预测的行为。

3）为了使它起作用，可能要实现优化以使不可变类型至少在几乎所有情况下都与可变类型一样有效，这是先决条件。 特别是，编译器应该聪明地通过引用传递大型不可变类型。

更新：我曾经有record而不是struct ，但是record!太像动词了。 我想到了其他一些选择： newtype ， typedef （这会使C程序员迷惑10秒钟）， composite或concrete就像上面提到的那样。

v0.6功能冻结之前，此空间中是​​否可能会发生某些事情？

鉴于尚未做出任何决定（至少是公开决定），而且距离冻结只有10天的时间，因此可能不会。

我没有仔细遵循，但是有一个评论是，如果/当这种情况确实发生变化时，我想要求我们首先对存在问题的文件/行号进行非常好的报告。 或者至少是模块； 在0.5中，有时甚至很难找出哪个包具有@deprecate d _binding 。

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