5 ms·

> Type identifiers should be in PascalCase [1] I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of th

> Type identifiers should be in PascalCase [1] I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of the built-in types such as 'string', 'set', 'int64', etc. are lowercase... it's annoyingly inconsistent. [1] https://nim-lang.org/docs/nep1.html#introduction-naming-conventions https://nim-lang.org/docs/nep1.html#introduction-naming-conv...

alkonaut 7y ago
In C# the lowercased ones are keywords, some of which map to built in types. For example "string" is a keyword that always means the type String (System.String). The word name "String" could be a type that some nefarious person added to your current namespace
treeform 7y ago
I think it does set the built-in types apart for being built it. Also tradition?
- excursionist 7y ago
  That makes about as much sense as making builtin functions UPPERCASE. Also, what tradition?
nemetroid 7y ago
I like it. It lets the domain-specific types stand out.
19ylram49 7y ago
On the contrary, I feel that the stylistic [and sometimes semantic] separation of primitive and boxed types in languages (e.g., `byte` VS `Byte` in Java) improves the developer experience, in that I can very quickly dissect the type of value that I’m dealing with when reading the code.
- scottlamb 7y ago
  In Java that difference matters a lot for performance: primitives are unboxed, objects are boxed. (Not as true now with auto boxing and escape analysis, but this was absolutely true in version 1.0.) In C++ it can matter for correctness because primitives are uninitialized by default. But other types might be too and the standard library uses under_scores for things that are initialized on construction, so it's not a great example of this distinction. Why do you care in other languages? In Rust for example I'm a little fuzzy on why I care if something is considered a primitive.
  - jdkardia 7y ago
    In this case it might be a 'documentation as code'thing, being able to see at a glance if something is a language primitive or a potentially very different implementation could have value. However I'm not super familiar with Rust, so I couldn't speak to that why.

alkonaut 7y ago

In C# the lowercased ones are keywords, some of which map to built in types. For example "string" is a keyword that always means the type String (System.String). The word name "String" could be a type that some nefarious person added to your current namespace

treeform 7y ago

I think it does set the built-in types apart for being built it. Also tradition?

excursionist 7y ago
That makes about as much sense as making builtin functions UPPERCASE. Also, what tradition?

nemetroid 7y ago

I like it. It lets the domain-specific types stand out.

19ylram49 7y ago

On the contrary, I feel that the stylistic [and sometimes semantic] separation of primitive and boxed types in languages (e.g., `byte` VS `Byte` in Java) improves the developer experience, in that I can very quickly dissect the type of value that I’m dealing with when reading the code.

scottlamb 7y ago
In Java that difference matters a lot for performance: primitives are unboxed, objects are boxed. (Not as true now with auto boxing and escape analysis, but this was absolutely true in version 1.0.) In C++ it can matter for correctness because primitives are uninitialized by default. But other types might be too and the standard library uses under_scores for things that are initialized on construction, so it's not a great example of this distinction. Why do you care in other languages? In Rust for example I'm a little fuzzy on why I care if something is considered a primitive.
- jdkardia 7y ago
  In this case it might be a 'documentation as code'thing, being able to see at a glance if something is a language primitive or a potentially very different implementation could have value. However I'm not super familiar with Rust, so I couldn't speak to that why.