On constructors
This commit is contained in:
9
main.cpp
9
main.cpp
@@ -23,6 +23,15 @@
|
|||||||
// problem is that complicates parsing a lot cause you have to account for multiple
|
// problem is that complicates parsing a lot cause you have to account for multiple
|
||||||
// indent styles, which means error messages become bad.
|
// 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
|
/// @todo
|
||||||
/// [x] - Typespecs should probably be expressions so stuff like would be possible :: *[32]int
|
/// [x] - Typespecs should probably be expressions so stuff like would be possible :: *[32]int
|
||||||
|
|||||||
@@ -166,7 +166,6 @@ parse_expr_call(Ast_Expr *left){
|
|||||||
token_expect(TK_Assign);
|
token_expect(TK_Assign);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
Ast_Expr *item = parse_expr();
|
Ast_Expr *item = parse_expr();
|
||||||
Ast_Call_Item *item_comp = ast_call_item(token, index, name, item);
|
Ast_Call_Item *item_comp = ast_call_item(token, index, name, item);
|
||||||
exprs.add(item_comp);
|
exprs.add(item_comp);
|
||||||
|
|||||||
Reference in New Issue
Block a user