> -----Original Message----- > From: Larry Garfield <la...@garfieldtech.com> > Sent: Wednesday, May 29, 2024 10:03 PM > > On Wed, May 29, 2024, at 7:53 PM, Andreas Hennings wrote: > > Hello Larry, > > just a quick thought. > > Is there a reason why we cannot just make it "public private string > > $x" instead of "public private(set) string $x"? > > We would define that the second visibility specifier is for write. > > > > The current proposal with "public private(set)" is less ambiguous, and > > it is immediately obvious that this is something new, and not just > > somebody accidentally added two modifiers. > > At the same time, it feels a bit alien and cluttered. > > > > Other options could be something like "public:private" or "public- > private". > > > > A consequence of such options would be that you always need to specify > > the read visibility along with the write visibility. > > But this seems ok to me. > > > > This is not a final opinion, just a thought.
> We went through a bunch of syntax variations last year, including "public > private", "public:private", and "public private:set", plus a few others. > In an RCV poll, public private(set) was the favorite. (See link at the end > of the RFC.) It also allows for extension to other operations and scopes, > and for the short-hand syntax. Many of the other options did not support > those. Thus we stuck with the known syntax that had the most flexibility > and most support. Would it make sense to do another RCV poll now that hooks are accepted, after lengthy discussion over its syntax? Personally, I would prefer the HookEmbeddedStyle form. I don't think the argument that the visibility would potentially be separated from the hook definition is very strong, as you would have to scan for the existence of the hook anyway. For me, asymmetric visibility and property hooks are mentally more related than the RFC technically defines them to be. Furthermore, I see a lot of reasoning in favour of the prefix syntax in relation to limitations of other language constructs like property promotion. While I don't think it is fair to expect this RFC should fix those, to me it feels we are compounding 'errors'. Thanks to both you and Ilija for all the hard work on these RFC's, it is much appreciated! -- Vincent de Lau
