The Rust Programming Language Forum

I suggest you get yourself familiar with the concept of expression-based languages. The semicolon is not a styling decision, it plays a critical role to separate expressions from statements, as simonbuchan already pointed out. It is true that an indentation-based solution could have been chosen instead, but then you are only exchanging one syntax for another, and it's arguably which one is better. Personally, I don't like indentation-based syntax, I find it harder to parse.

I am deciding the stack I want to use to create the macro. Do you have library stack option for creating proc macro that you know it is easiest possible to use and compiles fast? Not syn because it is slow

Imo getting input whether it is ugly or not from someone that already familiar with the language is not objective approach, it would consist bias of already know the thing. The most objective one would be taking someone that doesn't know the language yet, ask show them a little of many code example. That is why there is language that people easy to click with it, and hard to click with it The tree diamond a , i>, z> is hard to scan if it scales to complex. It introduces cognitive load because to scan the start to determine which one the child that I search, that child has what siblings Reading thing liniearly naturally be understood easier even almost without effort by brain, where reading thing that jump requires effort Semicolon is also noise, after technique to create language without semicolon is discovered. It put unnecerery particle when be combined with many other code it looks something convoluted from the top. Reading word that is clean is easier than word that consist of many symbol, look fresh to the eye Modern languages removes semicolon but keep block, it is unfortunate that Rust grammar was already created to require semicolon >,<. I wonder would it possible to make it work with or without semicolon, like Javascript and Odin previously it requires semicolon then it was made optional can remove semicolon

amid.ukr: type-based dispatch from a fieldless enum Is a bit of an oxymoron: a fieldless enum, once instantiated, is no longer a type - it's a value : a plain u8 for a fieldless enum with MyVarTraitAuto for T {} Full example here .

@discobot start tutorial

Eh, ugly syntax is often just a factor of familiarity as already mentioned. If you've used more languages than just C and Java the trailing type annotations (a common complaint) is much nicer to deal with, the consistent item / expr / block behavior is a delight compared to just about any traditional expr / statement language, etc. I have a few complaints (I'm very much not a fan of the lambda syntax, fn items not being excluded from the last item return rule, the complexity added by using <> for generics, fn return type using -> instead of : , ...), but overall I'd put it pretty high up.

I am a new user to the Rust community. How to start the new user tutorial 2 posts - 1 participant Read full topic

I am a new user to the Rust community. How to start the new user tutorial

Thank you, macro seems the better way and easily portable, I just need to extend the #[fn] macro then. For the return without keyword return, my algorithm is if it is at the end don't add semicolon. But I feel like prefer to remove it too aka must type keyword return for clarity. The difficult part is yes like you said, how to make the error line info represent the original code, not the proc macro project >, ,<. Removing 1 noise will improve readability in many line of code

my experience with reviewing (and writing tbh) Rust code is that match is always underrated. It's oftentimes shorter than Option and Result methods, esp. when the transformation is not trivial.

That's either a proc macro or a build script, using the cargo provided OUT_DIR to handle target dir locking, is my guess for the closest thing it sounds kind you're asking for, but there's a bunch more you'd need to provide for this to be actually effective, such as a compiler front-end to remap errors to the source location and editor services (using a well done proc macro somewhat handles this for you) On top of all those considerations, note that the presence of semicolon has a semantic meaning in Rust already; the last item in a block is implicitly the value of the block if it lacks a semicolon. There's some ways you could handle that, but you'd need type information for the nicer ones, which raises the bar a lot