On Fri, Mar 15, 2019 at 4:26 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Fri, Mar 15, 2019 at 4:16 PM Levi Morrison <le...@php.net> wrote:
>
>> Personally, I think pass by-value with copy-on-write semantics like
>> arrays is the sweet spot. Mutability is fine if it is localized.
>>
>
> If we introduce something like this, I think it is very important that it
> does not use the same property access syntax as ordinary objects, which are
> not copy-on-write. I do not want to be second guessing whether $x->y = $z
> is going to copy or not. Possibly such struct types should indeed use the
> array access syntax, because array access is generally copy-on-write (the
> exception being ArrayAccess objects).
>
>
>> I think having a no-constructor construction syntax is also a good
>> idea. I've discussed it with a few people, but don't can't remember if
>> it's ever been brought up on-list. Basically, the idea is to use a
>> JSON-like syntax with the type-name in front, and I think it can be
>> fine to use on regular classes that don't have a constructor too:
>>
>> struct Point2d {
>> float $x;
>> float $y;
>> }
>>
>> $origin = Point2D { x: 0, y: 0 };
>>
>> This syntax has no conflicts. We could also add an object literal
>> syntax for creating ad-hoc stdClass objects like so: `$obj = { x: 1,
>> y: 1}`. This has an ambiguity, but I believe I have solved the issue
>> without too much trouble once before.
>>
>
> This syntax has no conflicts in the sense that the grammar is unambiguous,
> but I believe it does conflict under LR(1). The problem is the alternative
> array access syntax, which makes Point2D { x } currently valid syntax. We
> can distinguish it at the ":", but by this point a shift/reduce descision
> on "{" must have already been made. (We can likely hack around this.)
>
Taking back this one: Turns out that we currently don't support the
CONSTANT{$x} syntax -- it's an oversight from the uniform variable syntax
RFC, which generally established syntax parity for the [] and {} array
access syntax, but missed support for this particular case. In this case it
happens to be in our favor :)
Nikita
