You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a meta-issue noting all kinds of issues related to differentiating of classes, class methods, etc. While the things are more or less working for ordinary functions and structs, there are lots of missed functionality related to classes.
Classes-type function arguments have reference semantics. Therefore they should be treated semantically similar to inout arguments, however, there are lots of subtle differences. In particular, we need to fix activity analysis for classes, determination of semantic results, etc.
There are lots of interesting special things around classes including e.g. accessors. Setters work by a chance (however, the activity analysis in anything involving setters is just plain wrong), and we do not support read / modify accessors.
To support read / modify accessors we need to implement missed pieces of functionality around differentiation of co-routines. While semantically it is unclear how one could derive a derivative of function that essentially might return different values in general, we can narrow down task to support only @yield_once co-routines, where everything essentially returns only once, there is no way to resume / abort co-routine, so they act as a normal functions and @yield_once is just a way to transfer ownership.
Quick check: do we have non-toy motivating use cases for class differentiation? If yes, could we please share them here?
Features like class differentiation involve many design decisions, and it's nice to do use-case-driven development to ensure decisions are made in support of real use cases.
Uh oh!
There was an error while loading. Please reload this page.
This is a meta-issue noting all kinds of issues related to differentiating of classes, class methods, etc. While the things are more or less working for ordinary functions and structs, there are lots of missed functionality related to classes.
read / modify
accessors.read / modify
accessors we need to implement missed pieces of functionality around differentiation of co-routines. While semantically it is unclear how one could derive a derivative of function that essentially might return different values in general, we can narrow down task to support only@yield_once
co-routines, where everything essentially returns only once, there is no way toresume / abort
co-routine, so they act as a normal functions and@yield_once
is just a way to transfer ownership.Related issues:
The text was updated successfully, but these errors were encountered: