-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Spec and implement structs in the parser #134
Comments
From the design meeting, we agreed that named tuples + type aliases are the way to go. For example: type MyType = { x: int, y: int, z: real }; would represent a struct with a name. The only downside I can now think of is that the following two "structs" are basically the same type which may be undesirable:
These two types do not have the same meaning and the user probably doesn't want implicit conversion between them. That is, we don't want the following to work: let p: Price = { value: 5 };
let w: Weight;
constraint w == p; // or just `let w: Weight = p` For enums, we ended up going with an struct Price = { value: int };
struct Weight = { value: int }; // Now this is entirely different from `Price`
enum Colour = R | G | B; One final alternative here is to make type aliases actually different types, which is not the case in Rust. But that also mean someone could create two different aliases to @otrho what are your thoughts here? |
So we could consider And then we can ask how useful is a type alias in a language without generics? 99% of the uses of I dont' think we need aliases and should just use 'newtypes' and then all of the above problems go away. |
Closing in favour of #139 |
Basically named tuples really. Start with simple records. We can later evaluate if we need more complex features such as
impl self
.The text was updated successfully, but these errors were encountered: