RFC: Syntax for read- and write- access to properties

[asajeffrey]

Still a draft as we are exploring the design space.

[vegorov-rbx]

Doesn't seem possible with current inference rules for read-only and write-only properties:
https://github.com/Roblox/luau/blob/master/rfcs/property-writeonly.md#adding-read-only-and-write-only-properties

In the example below, assignment of Dog.new() to x.pet will make pet property read-write.

[asajeffrey]

Once we've got local type inference, we'll get different read and write types. In this case we'll get a free type X with constraints X <: { get pet : Animal } and X <: { set pet : Dog }, so solving those constraints gives different read and write types.

[LoganDark]

Adding a new sigil to Luau is probably not the best course of action here. I vote against @-attributes.

[asajeffrey]

We may end up with attribute for things like API documentation, deprecation, etc. The syntax which most languages seem to have adopted is @attribute.

[asajeffrey]

(Sorry for the delay, it's been the winter break!)

[alexmccord]

I think this RFC as proposed leaks too much implementation detail and increases the complexity of type annotation grammar in general. I was hoping that we would arrive at something like:

{ animal: Animal } means animal is read-write.
{ readonly animal: Animal } means animal is read-only.
{ writeonly animal: Animal } means animal is write-only.

This also means it's not too confusing because you don't have two fields of the same name with different types with a read/write dichotomy.

Even better yet, we don't need to expose the writeonly syntax whatsoever because there's no need for it in Luau.

[asajeffrey]

@alexmccord We could just provide new syntax for read-only and write-only properties, and then use intersections to construct types with different read and write types.

[zeux]

This PR is closed as part of RFC migration; please see #1074 (comment) for context.