Personally I would much rather alter the accessor macros to allow property self.foo : Bar etc. I think the syntax is much nicer.

@RX14 I'd prefer that too but since #receiver is available only for Def type I'm not sure if it's possible to implement ATM or how to do it. Any ideas?

Looks like self.foo : Bar isn't actually valid syntax to pass to the macro at the moment. Could we change that @asterite?

@RX14 I thought about that, but what does it mean by itself?

@asterite just a TypeDeclaration with an invalid left side. We already use some syntax that lexes but will never compile (unused variable etc.) for macros. I imagine that a TypeDeclaration can specify pretty much anything on the left hand side.

@RX14 I still like the conciseness of property self.foo syntax but on the second thought that would leave string/symbol variant of property "foo", :foo without an equivalent, thus bringing IMO inconsistency to this feature. Also, that would be less ruby-like which uses more verbose version (class_attribute in rails for example). Therefore I'd still suggest using proposed solution, especially when there's no need for syntax changes or extra work on the compiler side to make it happen.

Is there really any reason why the old syntax exists? It's much less flexible in that you can't add type restrictions or defaults.

@RX14 what do you mean by "old syntax"?

:foo and "foo". They have to be constants anyway, so why not just use barewords.

:foo was the first syntax it was supported, then, when some type restrictions were wanted to be supported the idea of using type declarations foo : Foo or a call / bare word foo fit.

I wouldn't mind dropping :foo con consistency.

I understand the motivation of allowing property self.foo. Crystal/ruby use self. prefix for class methods. But class_property seems a bit more declarative to me.

@asterite @bcardiff Is this PR GTG for you?

@Sija I have to review this. Even though I kind of agree with the name, reusing all the logic and having macros inside macros obfuscates the code quite a bit. But I guess it's harmless. I'll review it soon :-)

@asterite Sure, even GH doesn't want to display the diff from default ;) I agree it ain't look gr8, but that was the only sensible way I've found to implement this feature without blatant copy-pasting all of the code once moar...

@asterite If this is GTG I'd send next PR simplifying macros in question if that's OK with you. It would save some bytes and simplify the code.

@Sija Don't worry, I'll soon review the code and probably merge it. These macros are almost fundamental and they won't change over time, so it's not that problematic if we use nested macros here.

@Sija I reviewed this and I think it's really good. I'm glad we can use macros inside comments to generate nice docs :-)

I just made a tiny comment for improvement. After that I'll merge this.

@Sija Thank you! 💙