<feed xmlns='http://www.w3.org/2005/Atom'>
<title>slang.git/tests/language-feature/properties/property-syntax.slang, branch master</title>
<subtitle>Making it easier to work with shaders</subtitle>
<id>https://git.yummers.dev/slang.git/atom?h=master</id>
<link rel='self' href='https://git.yummers.dev/slang.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/'/>
<updated>2020-08-13T17:36:55+00:00</updated>
<entry>
<title>Allow both traditional and modern property syntax (#1487)</title>
<updated>2020-08-13T17:36:55+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoleyNV@users.noreply.github.com</email>
</author>
<published>2020-08-13T17:36:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=09adf10f646f01e177d412ba2d86602a51579b4f'/>
<id>urn:sha1:09adf10f646f01e177d412ba2d86602a51579b4f</id>
<content type='text'>
The initial change to introduce `property` declarations tied them to a "modern" syntax:

    property width : float { ... }

In practice, a great majority of users assume that properties in Slang will be declared like those in C#:

    property float height { ... }

This change allows both options to parse correctly.

The choice made here is to only parse as the "modern" syntax when it can be detected from lookahead (an identifier followed by a `:`), and fall back to the "traditional" syntax otherwise. That choice might not produce the best diagnostic messages around syntax errors in codebases that use the modern syntax, but it is the easiest trade-offs to make.

We also add similar disambiguation logic for the `newValue` parameter of a `set` declaration (and other "modern"-style parameters). This strategy cannot be applied to all function parameters in general, because traditional parameter lists can still use `:` to introduce a semantic.

Note: the same disambiguation strategy applied here could be used for `let` and `var` declarations:

    let a : int = 1;
    let int b = 2;

This change does not try to introduce flexibility like that, because it seems unlikely for users to care.</content>
</entry>
</feed>
