Asymmetric Visibility v2

For those saying "No," ask yourselves if it's the feature itself you're opposed to, or the level of knowledge you will need in order to use it properly. Then ask whether you'll need this language feature. If you don't need it, don't use it. If you don't want to learn it, don't. But I feel it's good for the language to regain traction in the development space if it's capable of the same patterns as others.

Aside from competition, I like this feature for the following:

• Eliminate getter/setter methods that are nothing but cruft on top of direct read/write access of the property. Get back to writing functions that do things, not just carry the property in and out of the object.
• Control object state more flexibly instead of micromanaging properties between parent/child inheritance
• Reduce the boilerplate of constructors having to declare parameters instead of promoted properties, then pass the argument up to the parent's promoted property.

The syntax in the RFC adds complexity, yes. But we've all gotten used to other degrees of complexity as the language has grown and matured. Remember when visibility wasn't even a thing yet? Remember when constructing an object required a method matching the class's name? Growing pains hurt sometimes, but that doesn't mean they're not worthwhile.

I like the feature but don't like the syntax. something like this is better:

private writable $var;
private readable $var;

Way to confuse new developers! Let's learn them to write private private(set) readonly string $foo; so they want to stop developing and consider starting careers in other fields...

As with a lot of new exceptions to the standard, where do you draw the border in introducing new stuff? Do you also create super custom Exception classes like BookWithTheSameTitleAlreadyExistsException?

What does introducing 'asymmetric visibility' really solve? Writing a bit of boilerplate? Should we then also make an rfc to replace try-catch in a function with something stupid as a fallback in case something throws Exception/Error/etc. or something?

Programming languages should focus on readability for developers. Computers can handle complexity without a sweat, but we as people have limited brain power. Personally, I like to keep my code simple. It should require as little brain capacity as possible to read through my code. That way, we can focus on the general flow and possible bugs.

I don't have any arguments to add other than: It adds a lot of complexity and potential confusion for (IMO) negligible gain.

I would really like to see actual use cases (and less foobar) because I truely can't think of valid ones.. For mutable constructs I would just use methods to change the state and for immutable constructs readonly does the trick for me.

clone with would be nice, but this works reasonably fine for me:

final readonly class SomeClass
{
    public function __construct(
        public string $prop1,
        public bool $prop2,
    ) {}

    public function with(
        string $prop1 = null,
        bool $prop2 = null,
    ): self {
        return new self(
            $prop1 ?? $this->prop1,
            $prop2 ?? $this->prop2,
        );
    }
}

to be used with named arguments like

$someClass->with(
  prop1: 'changed',
);

It is confusing for me, I think readonly is enough for most use cases, this will be complex and probably will not cover some edge cases, so new features will be placed on top? It should not be in the language.

Let us rather remove the writeonce behavior from readonly and add a separate writeonce keyword.

The private(set) syntax is also ugly.