[moss2]

> Onyx is strictly type-checked. However, the type-inference systems in Onyx usually allow you to omit types.

>

> x := 10

I...

Why is this a feature in every new language? Can't we have a language that is more verbose and explicit, not less? I'd love it if named parameters were mandatory, not optional.

(Named parameters is when you name parameters/arguments you pass on to functions, like you can do in python and groovy: `foobar(arg1: 123, arg2: 'hello')`)

Most of my problems I run into is due to implicit behaviour that no one bothers to explain. In Onyx here, having type-inference means I now how to remember that x := 10 means x will be a signed 32-bit integer instead of, you know, the code that I'm writing remembering it for me.

And I'm just guessing here. Maybe x is a double. Or unsigned since its initial value isn't negative. Or maybe it was signed 32-bit integer but the Onyx developers changed it to 128-bit long long for version 666.0.0. The point is I have to look this stuff up or remember it instead of, you know, it being right there.

I don't even know what you gain by doing this. Less code is less messy but also hides a lot of information from you. Hiding information should be something an IDE does, not the language itself.

Thank you for reading my rant.

[justinpombrio]

Well on the other end of the extreme we had Java, which had an awful lot of this:

    HashMap<String, List<int>> hashmap = new HashMap<String, List<int>>();

Latest Java lets you omit the left type annotation (I hear, haven't tried it):

    var hashmap = new HashMap<String, List<int>>();

And in many languages the type parameters on the right can also be inferred --- so long as later code determines them --- so you get something like:

    var hashmap = new HashMap();

Hopefully we can all agree that the first option is needlessly verbose. There's more contention between the last two, I think.

My preference would be to do some type inference, but maintain the property that you can tell the type of every expression without looking outside of it (except perhaps for an immediate enclosing function call). This requires, for example:

- The third option isn't allowed, you need to write the second option instead.

- You must annotate function argument types.

- In Rust, you couldn't write `.collect()`, you'd instead write `.collect::<Vec<_>>()`.

- The `x := 10` example is actually somewhat ambiguous. If the language fixes the type of `10` then `x := 10` is legal. If it's an unspecified type (as is typically the case), you'd have to write the type down.

[stcg]

> The `x := 10` example is actually somewhat ambiguous. If the language fixes the type of `10` then `x := 10` is legal. If it's an unspecified type (as is typically the case), you'd have to write the type down.

For that case I like a type signifier as part of the number literal expression, like this: `x := 10f32` or `x := 10i32`.

[Nevermark]

I have often used a Java utility class of static inferring generic constructors:

    public static <E> ArrayList<E> newArrayList() { return new ArrayList<E>(); }
    public static <K,T> HashMap<K,T> newHashMap() { return new HashMap<K,T>(); }

So code can look simpler, but just as clear:

    import static GenericConstructors.*;

    ...

    ArrayList<String> names = newArrayList();
    HashMap<String, List<int>> hashmap = newHashMap()

The "x := 10" example is one reason it feels safer to me to declare the variable type, and infer the constructor types, than the other way around.

--

What would resolve this whole issue is standardized editor/IDE visualization support for showing all inferred types, just one toggle button/key away.

Inferred types simplify writing code. But when reading code, why should we have to mentally emulate the language's inference algorithm? It is, by definition, supposed to be automating that for us.

[vips7L]

> Well on the other end of the extreme we had Java, which had an awful lot of this: HashMap<String, List<int>> hashmap = new HashMap<String, List<int>>();

This is untrue. Inferring diamond types has been built into the language for over a decade.

    Map<String, List<Integer>> map = new HashMap<>();

[moss2]

Would you be willing to use a language that looked verbose in the text files, but you had an IDE that hid the verbose parts from you?

Take your Java example. If the code in the .java file looked like

    HashMap<String, List<int>> hashmap = new HashMap<String, List<int>>();

but IntelliJ showed it to you like

    hashmap = new HashMap();

[kstrauser]

I see what you mean, but do appreciate the quality of life improvement of such things. In your example, that looks a lot like a native int. It might be something different, but 99.9% of the time it’s going to be an int. I think it’s reasonable to say that unless told otherwise, a thing that looks like an int is an int. Same with `x:=3.14`. That could be a long double, but it’s vastly more likely to be a plain old float. Why not make that the default?

An extra advantage I see is that non-default types stand out. At a glance at the code, `x:=10` is the most common int type. It’s plain, unadorned. It’s the usual, boring thing. Things that are less common stand out: oh, this is unsigned for some reason. Guess I should see why. I like the pattern where unusual things are easier to visually scan for.

But at the end of the day, darn it, compiler, you know very well that I mean 3.14 to be a float. Stop making me say so each time!

[moss2]

I can't remember which language, but there is one where every number is a double and there is no int type.

Is Onyx like that? I don't know. It would take me maybe two minutes to look up. The point is I have to look it up to be certain when that certainty could be part of the language.

[giraffe_lady]

The other side of "why do I have to remember this when I could write it" is "why do I have to write it when the compiler already knows it?"

I love complete inferred type systems, using one has completely changed how I think about types and what I expect from a programming language. I feel ill every time I have to use go or typescript. Like I am teaching the compiler how to compile. This is not my job, it's a waste of time and energy, it should already know. Things like rescript and ocaml are where my attention is going for typed languages in the future.

[cobbal]

Same reason we don't have to type `(((2int + 2int)int) / 8int)int`. Type inference already exists in any ALGOL-like. Modern languages just tend to remove the arbitrary restriction that variables are the places where types must be added.

[trealira]

In C, there's no type inference. Integer literals have the type "int" by default, and they need a suffix to be unsigned or long. They get truncated and promoted implicitly for convenience's sake.

  /* 'a' : int
   * 'a' is truncated to char (self-evidently safe here(
   */
  char c = 'a';
  /* 1 : int
   * c : char
   * c is promoted to int
   * 1 + c : int
   * 1 + c is truncated to char
   */
  char d = c + 1;
  /* d : char
   * c : char
   * d and c are promoted to int
   * d - c : int
   * d - c is truncated to char
   */
  char e = d - c;

If you want to avoid this behavior, you have to use the type suffixes explicitly, pretty much like that "(((2int + 2int)int) / 8int)int" expression you're making fun of.

  // Zero. 32-bit integer left shifted by 32 bits is always 0.
  1 << 32;
  // 2^32. "U" makes it unsigned.
  // "LL" makes it "long long", 64-bits on Windows and Linux.
  1ULL << 32;
  // -2147483648 (signed 32-bit)
  // i.e. 0x10000000
  1 << 31;
  // 2147483648 (unsigned 32-bit)
  // i.e. 0x10000000
  1U << 31;

I don't think this is a good thing. It's very confusing.

I prefer the type inference approach, e.g. in Rust, where they're i32 if the type cannot be inferred and the literal has no type suffix. And I like that no two integers can be used by the same binary operator unless they have the same type, so you need to explicitly cast them to the right type.

[Joker_vD]

Well, technically

    int(int(int(2) +::<int> int(2)) /::<int> int(8))

We must disambiguate integer- and float-point arithmetic operators for sure.

[dragonwriter]

> Same reason we don't have to type `(((2int + 2int)int) / 8int)int`. Type inference already exists in any ALGOL-like.

That's not why you don't have to do that.

Many (most statically typed?) Algol-likes have strict types for literals (e.g., 2 is always a signed int, if you if you want specifically unsigned you might say 2u and if you want a double you say 2.0, and if you want a single-precision float you say 2.0f, or something) and strict rules at how math between them works and what types it produces, this has been true since long before tyoe inference became common, and is why you don't have to say 2int+2int — 2 is syntactically defined as int.

There is no inference

[Joker_vD]

Reasonably, x in this case would be generic/polymorphic (just as 10 is a generic/polymorphic constant) with its type bounded by the equivalent of Num trait. Haskell (and to some extent Go) gets it right.

Also reasonably, each source file should start with declaring the version of a language it was written in, so that e.g. Onyx 666.0 changing its default integer width wouldn't affect the code in the file with "///OnyxVer=665.0" at the top of it. Now that is a feature I would like every new language to have.

[wharvle]

I think it’s fine if and only if there are 1st party tools for editors to provide hints about the type the language will infer. If I can mouse over and see the type it thinks the var is, and see static analysis errors if I try to treat it as the wrong type without casting first, then it’s fine.

That is, as long as the core tools for the language provide that info somewhere that’s not more than barely more hidden than explicitly typing it out, I think that’s Ok.

[dragonwriter]

> Why is this a feature in every new language?

Because superfluous type checker incantations are, aside from breaking up flow of thought when writing code, annoying visual noise when reading it.

> I'd love it if named parameters were mandatory, not optional.

Named parameters are a different thing than type incantations, and I agree that it would be good for any non-operator function that takes more than 1 argument to require named parameters.

[rstat1]

>Because superfluous type checker incantations are, aside from breaking up flow of thought when writing code, annoying visual noise when reading it.

I disagree. Implicit typing for the most part makes things harder read. The less I have guess about what type something is the better. I never use stuff like "var" or "auto", unless forced to for this very reason.

[xigoi]

I don't see the value of, say, dot_product(vector1=x, vector2=y) compared to dot_product(x, y).

[gpderetta]

Programming is not unlike writing on an human language. Sometimes you use a proper noun, sometimes a pronoun sometimes you omit subject or object completely, even in rigorous technical writing. There is no hard rule, learning to communicate unambiguously and efficiently it is an art.

[goto11]

But that would only help you if you assign the numeric literal directly to a variable. If you use it in an expression like `foo(10)` or `10 * bar` you would still not see the numeric type specified.

So if you want the type to be always explicit, the type specifier should be coupled with the literal like `10[i32]` or similar, so you can write `foo(10[i32])`.

[moss2]

I might not be against that...

Assigning variables or calling methods (when you discard the return value) would look the same as is typical in many languages:

    int x = foo(); // foo() returns int but we can see that in what type x is
    foo(); // we don't care what foo() returns

Named variables in method calls would have to have the type so as to not hide what type a method-as-parameter returns:

    CoolObject cool_obj = bar(int arg1: foo())

[thefaux]

Imagine if you had to write english sentences annotating every noun and verb "(Bob: Person) (went: Verb) to the (beach: Place)." That's what mandatory type annotation feels like to me.

[otabdeveloper4]

> Can't we have a language that is more verbose and explicit, not less?

What's wrong with the old verbose languages?

[mrweasel]

No no, I with you this, I hate that Go allows this as well.

If you have a type system, then force the user to specify exactly what type they want something to be. It's completely reasonable in my mind to write var x float32 = 10, the compiler can then deal with adding the .0 if it wants.

[bobbylarrybobby]

Eh, rust has pretty solid type inference (sounds like you'd hate it), but with the rust analyzer extension, you can get inlay hints that tell you the inferred type of every variable, so you're never actually left wondering. Seems like the best of both worlds.

[moss2]

I'd prefer the other way around. If the language was verbose but its tools (IDEs, analyzer extension) hid redundant info from you.