More macro sugar?


#1

If macros are to be used inplace of other features like n-ary functions and lots of other special case sugar, might it make sense to enhance them a little to fit visually with other syntax forms. The suggestions here can all be done with regular macros; these would just be ways to make their invocations read more naturally alongside inbuilt syntax.

1 ‘method macros’ $self.foo!(…) e.g. for n-ary wrappers for method calls. also might be nice for a chaining macro(see other thread). put a $self in there.

foo.chain!(push(1); push(2); push(3)); //expands as {foo.push(1); foo.push(2); foo.push(3)}

Would also allow macros themselves to be chained. foo.bar!(...).baz!(...);

Not suggesting any sort of polymorphism here, just positional convince, being able to make things read nicer.

[2] multiple brackets… foo!(…){…} eg cfor, or recovering something closer to old ‘do’ notation. Fight nesting levels

cfor!(i=0;i<10;i++) {
   loop body...
}

[3] preceding ident… foo! Bar { … } eg custom declarations, looking closer to inbuilt declaration forms

def_annotated_struct! MyStruct { 
    field1:type1,
    field2:type2...
};  
// rolls a struct with associated metadata

potentially useful combinations …

// rolls a struct and 
// a default constructor MyStruct::new(args..){ 
//        MyStruct{field1:initializer-expressoin1,field2:..}}

def_struct!  MyStruct(args..) { 
    field1:type1=...initializer-expression1,
    field1:type2=...initializer-expression2,
  ... //
}

collection.for_each!(x) {.. closure body..}    //for_each(collection, |x|{...body..}

#2

This all sounds good for me. There have been a number of “ergonomics” RFCs, and I think it would be shame to bloat the core language with ergonomics after the team has done such a good job at shrinking the language over the last year. Changes like this go a long way into trying to reconcile ease of use, and a simple and elegant core language.