Primitive type capitalization

[eladb]

Feature Spec

This is a proposal to change all built-in types to use lowercase instead of PascalCase, so they all have a similar look and feel, and are also distinguishable from user-defined types.

So basically the lowercase versions are just aliases:

• str
• num
• bool
• duration
• date
• json
• array<T>
• set<T>
• map<T>
• mutarray<T>
• mutset<T>
• mutmap<T>

Use Cases

To reduce cognitive load, all types should have a similar look & feel.

As an example, see the spec for Json, which proposes the all built-in types will have a from_json() method.

Component

Language Design

Community Note

Please vote by adding a 👍 reaction to the issue to help us prioritize. If you are interested to work on this issue, please leave a comment.

[MarkMcCulloh]

I disagree with the cognitive load argument for the case change, I don't think that's giving enough credit to developers who see that maybe these types are different (cause they are).

If it this ends up happening, then I would say the real cognitive load is that they're abbreviated. I would be more in favor of this (with aliasing):

str <=> String
num <=> Number
bool <=> Bool
duration <=> Duration

[eladb]

@MarkMcCulloh I like your suggestion. Yes, after submitting this issue I had a weird gut feeling that it's the wrong direction...

[eladb]

@MarkMcCulloh lmk if you this makes you happy.

[Chriscbr]

By aliasing do we mean these are both valid?

let fn = (message: str) => { `Hello, ${message}` };
let fn = (message: String) => { `Hello, ${message}` };

(Maybe we can also offer ~ as an alias for inflight? 😝)

I'm not sure I am convinced of the strong need/benefit for aliases here

[MarkMcCulloh]

I actually don't want aliases either, but I also dislike the pascal casing for primitives. So if we decide to do Pascal casing anyways, I'd love to be able to avoid it with aliases.

[eladb]

str.from_json() feels odd to me, so I want to be able to do String.from_json(), but I tend to agree that str, num, bool, json (!!) are much nicer for primitives.

Makes me wonder if we should also have array<T>? WDYT?

[eladb]

Yes, that's what I mean.

[Chriscbr]

I feel like what we want maybe are just global classes containing the utility methods for primitive types. That is, String is a class with utility methods about str, Number is a class with utility methods about num (like isNaN).... It's nothing original but I think it gets the job done.

[staycoolcall911]

+1 for @Chriscbr 's idea

[eladb]

Not sure I like this idea. It feels confusing that String doesn't really represent a string. If we just want a utility type, we can call it StringUtils, but this seems uncalled for.

Currently leaning towards aliases (str is an alias for String, num is an alias for Number).

Still not sure if this should be Str/Num...

[ekeren]

just pointing out that this feels inconsistent, unless we can explain how str is different from Json

str.from_json(json_string);
Array<num>.from_json(json_array);
num.from_json(json_number);
Json.clone(mut_json);

[eladb]

@ekeren I agree.

updated the description and added an alias for json as well.

[flyingImer]

I like the syntax of String.from_json, but not sure about having the alias: does that mean I can do both str.from_json and String.from_json? and even let a: str = "hello"; and let a: String = "hello"; in the same code base?

On the other hand, I am kinda into str.from_json (staring at it for a while), and mental modeling something like:

// primitive types
str.from_json(json_string);
num.from_json(json_number);
// container type
Array<num>.from_json(json_array);
// container-like type?
Json.clone(mut_json);

[eladb]

I like the syntax of String.from_json, but not sure about having the alias: does that mean I can do both str.from_json and String.from_json? and even let a: str = "hello"; and let a: String = "hello"; in the same code base?

Yes, all of these syntaxes will be supported.

[eladb]

Updated the description based on our decision from community meeting today. - basically we decided that all built-in types will use snake_case.

[staycoolcall911]

We decided to keep it ergonomic and use lowercase across our entire built-in types (so str, array, etc.). This makes this issue a good first issue to simply make this change consistently across the wing repo.

[garysassano]

@MarkMcCulloh Is this still relevant? Most types have capital letter now.

[staycoolcall911]

@garysassano - yes, that's still desired, would be great to have this change before the launch, since it's a big breaking change. Just discussed with @eladb and updated the list of types at the bottom. FYI - the only update we made is that since we recently got rid of snake case, we decided to remove the underscore from the mut types (so mutarray instead of mut_array).

[Labdabeta]

Has anyone considered going the way that Nim handles identifier equality. That way we don't necessarily have to worry about breaking changes if the code base changes, and people can use their preferred style if they want (add/remove underscores without worrying).

As a summary, PascalCase and underscore_case are implicitly equal such that WingLang, Wing_Lang, and WINGLANG would all be the same identifier.

[staycoolcall911]

Interesting, thanks for the idea @Labdabeta! I see the value for writers of Winglang, but there's downside on readability when there's no consistent format for types (e.g. str, Str, STR and maybe also String and STRING would all be the same).

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!