On constructors

This commit is contained in:
Krzosa Karol
2022-05-30 09:10:15 +02:00
parent c305d4da44
commit 54e3cb5261
2 changed files with 9 additions and 1 deletions

View File

@@ -23,6 +23,15 @@
// problem is that complicates parsing a lot cause you have to account for multiple
// indent styles, which means error messages become bad.
// 2022.05.30 - On constructors and compound expressions
// I unified the compound expression syntax (Type){} with function call syntax Type().
// It's differentiating on whether you used type. I think there is a benefit to the language
// not having an idea of overloading the type constructor. You will always know what will happen.
// Unlike C++ for example. It seems like a minefield that can fuck your mind up. So many corner cases
// and variants. having the idea of compounds doing one thing is reassuring I think.
// You can always do a constructor by writing a function with lower case type if you want that.
// For now I don't thing it should be overloadable.
//
/// @todo
/// [x] - Typespecs should probably be expressions so stuff like would be possible :: *[32]int

View File

@@ -166,7 +166,6 @@ parse_expr_call(Ast_Expr *left){
token_expect(TK_Assign);
}
Ast_Expr *item = parse_expr();
Ast_Call_Item *item_comp = ast_call_item(token, index, name, item);
exprs.add(item_comp);