Random discussion for v2 design and features

[Y-Nak]

This discussion aims to accumulate our random thoughts on v2 language design and features.
Each topic can be escalated to a concrete issue to proceed to an implementation step or further discussion.

[Y-Nak]

Remove the ~ operator and redefine ! as both logical/bitwise NOT.

Example

let x: u8 = !0 // working as a bitwise NOT operator. Returns `255` in this case.
let b = !false // working as a logical NOT operator. Returns `true` in this case.

Motivation

We replaced the not boolean operator with ! in v2.
It makes using ~ as a bitwise NOT operator redundant.

[sbillig]

I think this is probably fine, and rust does it, so...

! has strong boolean connotations, so we'll also have to copy rust's casting rules/methods to ensure we don't lead people into erroneous code. Eg using "v1" syntax:

let balance: usize = 0
let no_money = !balance
if no_money { ..
// ^ type error, expected bool. User might "fix it" by casting to bool:
if bool(no_money) { .. // no_money is u32::MAX, thus `true`
// or
if no_money as bool { ..

[Y-Nak]

I don't quite understand the connection between a casting rule and removing ~. e.g.,

let x = ~1;
if x { ... }

It seems what you said could be applied to this example as well.

Regarding casting, I do agree that having some form of casting is beneficial, but I prefer it to be safe casting only. For example, I am opposed to casting from integer primitives to bool or vice versa, as I just feel casting between unrelated types would be dangerous. I am also skeptical about having narrowing conversions as Rust does via as syntax. e.g., i32::MAX as i8.

About the syntax for casting, I am still unsure whether we should have special syntax for primitive casting. Having Into and TryInto traits in std might be sufficient.

NOTE: I don't insist on the idea of removing ~ operator. Leaving ~ symbol available for a new language feature might be beneficial, though.

[sbillig]

Ha, sorry, my example is fine, and not misleading to the user. Apparently simple boolean logic is too challenging for me.

I think that comparisons like x > 0 are the best way to "cast" an integer to bool. I think we shouldn't have any special casting syntax; Into and TryInto are fine. Though I don't really like rust code with .into() sprinkled everywhere, and ergonomically, automatic widening of ints is nice. array[some_u32] being an error in rust is annoying.

We should probably also have explicit truncating and clamping narrowing, eg my_u64.truncate_to<u32>() and my_u64.clamp_to<u32>().

[Y-Nak]

I think there might be a misunderstanding in this conversation.
I didn't mean a boolean logic, nor anything pedantic.

Please let me rephrase it.
My question was about whether the error message in your example is issued specifically when the result of applying ! to an integer is passed into a context that expects a bool. That is, I was unsure whether a similar error message would be reported if the ! in your example were replaced with ~ in case we keep ~ as a bitnot operator.
In other words, I didn't understand well whether you suggested that we should emit the same error message at !balance if we leave ~ as is.

[Y-Nak]

Tuple struct

Example

struct Foo(pub i32, u32)

Motivation

1. Tuple struct is especially useful for new type idiom
2. We've already implemented a tuple enum variant, which makes it weird not to have a tuple struct, especially if we add the "Variant as Type" feature

[Y-Nak]

Allow specifying visibility in tuple variant

Example

enum E {
    Record {x: i32, pub y: u32},
    Tuple(pub i32, u32)
}

Motivation

1. Visibility for fields in a record variant is already allowed
2. This would be helpful when we want to restrict the construction of a specific variant

[Y-Nak]

Literal suffix for integer types

Example

let x = 1i32
let u = 1u32

Motivation

• This feature would mitigate the pain of adding type annotation, mainly because we decided not to have a fallback in integer type inference.

[Y-Nak]

Type ascription to sub-patterns(or also to sub-expression).

Example

let (x: Vec<i32>, y) = (i.collect(), false) 

let x = Option::None
match x {
    Some(_: i32) {}
    None {}
}

Motivation

1. This restricts the location where type annotation is required.

[Y-Nak]

Enum variant as type

Example

enum Expr {
    Bin {lhs: Box<Expr>, rhs: Box<Expr>, op: BinOp}
    Un(Box<Expr>, UnOp)
    ...
}

fn check_bin_expr(expr: Expr::Bin, expected_ty: TyId) -> TyId {
    let op = expr.op
    ... 
}

fn check_un_expr(expr: Expr::Un, expected_ty: TyId) -> TyId {
    let op = expr.0
    ...
}

Also, it'd be great if we could implement a type narrowing, which is automatically performed depending on the context.

fn check_expr(expr: Expr, expected_ty: TyId) -> TyId {
    match expr {
        // The type of `expr` is narrowed to `Expr::Bin` here.
        Expr::Bin(_) => check_bin_expr(expr, expected_ty),
        // The type of `expr` is narrowed to `Expr::Un` here.
        Expr::Bin(_) => check_un_expr(expr, expected_ty),
    }
}

Assuming the subtype relation between the variant type and its parent enum type, the code below is also well-typed.

fn foo(x: Result<i32, String>) {
    match x {
        Ok(_) => {
            handle_i32(x) // fn handle_i32(x: i32)
            handle_result(x) // fn handle_result(x: Result<i32, String>)
        }
        Err(_) => {
            handle_string(x) // fn handle_err(x: String)
            handle_result(x)
        }
    }
}

[g-r-a-n-t]

Trait aliases

This feature might be helpful with grouping things like number operations.

example:

trait Add<Out, RHS> {}
trait Sub<Out, RHS> {}
trait NumOps = Add<Self, Self> + Sub<Self, Self>

in rust

https://doc.rust-lang.org/beta/unstable-book/language-features/trait-alias.html