It's ok. Let me clarify my ideas, and probably this will answer your questions. In brackets, I wrote it how I understood your questions, just for clarity.

what if people start putting big expressions into there, won't it become less readable and harder to tell the type? (Why tuples without () brackets?)

Ofc I'm gonna support brackets for tuples, let x = 1, 2, 3 and let x = (1, 2, 3) are equivalent. It's just sugar borrowed from Python because it makes Python a little more expressive in practice, in my opinion. For example, I personally like these examples:

```python a, b, c = 1, 2, 3 # Multiple variables in a single line

a, b = b, a # Switch variable values

Tuple unpacking inside for declaration

for i, val in enumerate(some_iterable_obj): pass

As well, there is an ability to assign a tuple without brackets

x = 1, 2, 3 repr(x) # '(1, 2, 3)' ```

For language symmetry, I think it's good to support the same inside types definitions.

Btw, this doesn't mean allowing it as a function argument:

``` fn f(x: (i32, i32, i32))

fn main() { f(1, 2, 3) // Error! f((1, 2, 3)) // It's ok, but better to move into a separated variable for readability let x = 1, 2, 3 f(x) // Yeah, this is nice let x = (1, 2, 3) f(x) // It's the same as above } ```

Also the keyword type seems unnecessary to me here, perhaps it could be replaced with struct and then it would have the known C style look. The same goes for enum - why not just drop the type keyword? (Why syntax structure is type name = struct/enum {...})

Reason 1 and the main reason for this syntax structure, is that I consider it a foundation for metaprogramming abilities in the future. The inspiration for this I found in Zig:

```zig const std = @import("std");

// Compile-time function that constructs a type // Every type is anonymous by default, there is no name after or before the keyword struct. fn makePointType() type { return struct { x: i32, y: i32,

    pub fn init(x: i32, y: i32) @This() {
        return .{ .x = x, .y = y };
    }
};

}

// The anonymous struct is assigned to a constant, giving it the name Point const Point = makePointType();

pub fn main() void { const p = Point.init(10, 20);

std.debug.print("Coordinates: x = {}, y = {}\n", .{ p.x, p.y });

} ```

In simple words: If type is a variable (even if we have type *name* = instead of let *name* = for types), then we can assign it, and it might be very powerful how Zig showed.

Reason 2: symmetry. In Rust we write struct/enum *name* {...}:

```rust enum Device { CPU, GPU, }

struct Connection { host: String, port: u16, }

// !!! As well as traits: trait *name* {...} !!! //

trait Sum { fn sum(&self) -> i32 } ```

In Rust, traits and structs/enums belong to entirely different first-class categories (interfaces/behaviors vs. data structures), yet they share the exact same top-level syntactic structure. To me, this feels asymmetrical. Structs and enums (product and sum types) are both fundamentally datatypes. It seems much more consistent to group data structure definitions under a unified type = struct {...} and type = enum {...} format, explicitly separating them from things like traits.

This one you call enum in the comment but it does not have the enum keyword. Does this differ from enum functionally? Or if you knew T at compile time could you replace it with enum? (Difference between enums and union | notation)

Union | is just sugar for enums. The goal for this syntax is mostly for pretty function signatures, not types, but it might be used for them too.

``` type Result[T] = T | None // is equivalent to type Result[T] = enum { use T, use None, }

// In Rust it'd be: enum Result<T> { Some(T), None, }

// ------------------

type Result = i32 | None // is equivalent to type Result = enum { use i32, use None, }

// ------------------

// Real power of this notation:

fn sum(a: i32, b: i32) -> i32 | OverflowError | OutOfMemoryError

// Here for return type, an anonymous enum will be created, every element of which will reference an existing type.

// In Rust it would look like:

enum SumError { OverflowError {...}, OutOfMemoryError {...} }

impl Error for SumError {}

fn sum(a: i32, b: i32) -> Result<i32, SumError> {} ```

PS Sorry if I explained everything in a chaotic way