Open samuelgoto opened 7 years ago
@samuelgoto Note that this could be mitigated there by using case
, an existing keyword, instead (which I've already suggested in this alternate syntax proposal).
Thanks for the pointer! Intersting suggestion!
More generally, though, there is a broader question of whether we corner ourselves or not and how we should go about it (i.e. match() {} is a concrete example: suppose it we did indeed watch to use match, how would we go about it in the presence of this proposal?).
WDYT?
I personally feel the foo! { ... }
/foo!(arg) { ... }
syntax works well enough. I've had some limited experience with Rust, so I'm a bit desensitized to it.
ha, interesting, wasn't aware that rust provided a similiar feature. i knew about kotlin/groovy/ruby, but good to know that rust supports it too. can you give me an idea of how things look like in rust? what are the most popular uses of this feature?
On Sat, Oct 28, 2017 at 10:47 PM, Isiah Meadows notifications@github.com wrote:
I personally feel the foo! { ... }/foo!(arg) { ... } syntax works well enough. I've had some limited experience with Rust, so I'm a bit desensitized to it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/samuelgoto/proposal-block-params/issues/7#issuecomment-340239386, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqV6iJHulGFNLubiTuV9lBeYsf0OwEpks5sxBGBgaJpZM4P-akd .
-- f u cn rd ths u cn b a gd prgmr !
Rust uses hygenic macros, which are very different conceptually, but their usage frequently quack a lot like DSLs.
// Defined
macro_rules! foo { ... }
// Variant 1, usually used for function-like operations
foo!(...args_ish)
// Variant 2, usually used for creating list-like structures
foo![...entries_ish]
// Variant 3, usually used for DSLs and language extensions
foo! { ...syntax_ish }
Here's a few examples of how they're used by the language core:
From @bterlson:
From @samuelgoto:
A few of options to explore:
match
as a keyword which prevents functions from being declaredmatch
shadow polyfills.match
without loss of functionalityLeaning towards (2) since it doesn't corner from providing a built-in one. (3) sounds hard and (1) un-necessary.