On 5/16/21 12:48 PM, 12345swordy wrote:
> On Sunday, 16 May 2021 at 16:38:08 UTC, Steven Schveighoffer wrote:
>> On Sunday, 16 May 2021 at 15:45:48 UTC, 12345swordy wrote:
>>> ```struct TIntStatic
>>> {
>>>     static int mX;
>>>
>>>     static @property int x() { return mX; }
>>>     static @property void x(int v) { mX = v; }
>>>
>>>     alias x this;
>>> }
>>> ```
>>>
>>> It doesn't like the following code
>>> ```
>>>
>>> alias t = TIntStatic;
>>> t(5);
>>> ```
>>> Yet is perfectly fine with this
>>> ```
>>> alias t = TIntStatic;
>>> t = 5;
>>> ```
>>> What is with the inconsistency? If you allow t = 5 then surely you must allow t(5) as part of alias this a function.
>>
>> That’s considered a constructor. And there’s no member to accept the 5.
>>
> 
> You mean that this shouldn't work?
> ```
> alias t = TIntStatic;
> t = 5;
> ```

Honestly, I'm not sure. `alias this` usually maps to a `this`, i.e. an instance, not the type. I'm sure it's some quirk in how the compiler treats alias this, but I wouldn't have expected it to work.

But the reason the constructor form doesn't work is straightforward -- the constructor t() exists. Therefore, it matches first, not using the alias this, and it's just a matter of parameter count mismatch that fails (this is well-trodden ground).

BTW, is there a reason you are using `alias t` instead of the real type? If:

```d
TIntStatic = 5;
```

doesn't work, but yours does, then that seems like a bug to me.

-Steve

On 5/16/21 1:19 PM, 12345swordy wrote:
> It part of the test suit that the user jinshill has created.
> ```d
> TIntStatic = 5
> ```
> Works fine. It is just that I am puzzled by this weird edge case.

People can write tests that confirm invalid behavior. I wouldn't take the presence of a test as definitive confirmation that the feature should exist. Again, though, I'm not sure if it should.

-Steve