> would also be sensible syntax. But, the real monkeywrench here is that:
>
> def func1(x as int, y as float) as staticmethod:
>
> now looks like it *returns* a staticmethod, which is wrong.
>
> So, thanks to your argument, I'm now leaning a little more towards using
> [] rather than "as", because "as" looks like syntax that should be
> reserved for adaptation at a future time. :)
You're right. I had forgotten that Visual Basic uses "as" to specify
the return type of a function too.
I guess [] (or any list object) is better for method decorators.
Maybe in the future you could have something like:
def myfunc(x as int, y as float) [synchronized, staticmethod] as int:
...
So "as" is always and only associated with adaptation.
x = myfunc(1, 2.0)
--> means x = adapt(myfunc(adapt(1,int),adapt(2.0,float)), int)
p = q as int
--> means p = adapt(q, int)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4