[Pre? RFC] Partial types and partial mutability

language design
4

Thanks for feedback!

(1) Changes are next

(A) Change in types:

  1. Each specific type (not <T>), which is supported by partial type extension (Stucts and Tuples) has partiality (partial-access): has "SomeSt.%something" at the end or "SomeSt<T>.%something"
  2. If partiality is omitted, it means .%full. So SomeSt is same as SomeSt.%full
  3. partiality could be specific or general(St.%a) like lifetime, but we mostly use in specific form
  4. Full form of specific partiality is next: "St.%{%access1 fld1, %access2 fld2, ...}" where "%access = %permit | %deny | %miss | %ignore" and fld - are field names (or number for tuples).
  5. %permit field-access mean that field has access to read, to write (if mut), to borrow.
  6. %deny field-access forbid to have any access to read, to write, to borrow (like private fields)
  7. %miss field-access is same as %deny, but it is possible to convert into %permit
  8. %ignore field-access is quasi-access, it make unclear real field-access (%permit, %deny or %miss)
  9. We add some sugar: if field-access is omitted, it means %permit, if field-name is omitted, it field-access is %deny
  10. we add some sugar:
  • * - "all fields" quasi-field,
  • _ - "rest of fields" quasi-fields,
  • self - quasi-fields for unsupported types
  • %full = %{*} = %{%permit *} - full access,
  • %empty = %{} = %{%deny *} - no access
  • %any = %ignore _ - ignore rest of fields
  • %unfill = %miss _ - missed rest of fields
  1. All unsupported types has singe filed - self and it is always %permit, so these types are always %full

(2) Change in Variable use:

  1. Each used variable, which is supported by partial type extension (Stucts and Tuples) has partiality (partial-access filter): has "var.%something" at the end or "self.var.%something"
  2. Full form of specific filter-partiality is the same as partiality for type
  3. we add specific partial-filters, which depends from variable detailed partiality:
var part %max %exact
%permit %permit %permit
%deny %deny %deny
%miss %miss %miss
%ignore %deny %ignore
  1. we add specific partial-filters for arguments, which depends from detailed partiality of parameter of a caller function:
var part %arg
%permit %permit
%deny %deny
%miss %miss
%ignore %deny
  1. We add some sugar: if field-access is omitted, it means:
  • = .. &? mut? var ~ = .. &? mut? var.%max
  • return &? mut? var ~ return &? mut? var.%exact (explicit (?or implicit) return)
  • self.call( &? mut? var ) ~ self.call( &? mut? var.%arg )
  1. If we have a variable with %miss fields and make an reference (mutable or not), referenced partiality convert own %miss field-accesses into %deny (origin variable partiality remains the same).

(C) changes in parameters

  1. Parameter Type partiality could consist %ignore fields. All argument field-accesses must match with parameter's type and type field-access. Except %ignore fields.
  2. Inside function body ignored parameters fields are %ignore access
  3. %ignore filed is like %deny field (except for return)

(D) changes in initialization (and deconstruct match binding)

  1. Each used Constructor, which is supported by partial type extension (Stucts and Tuples) has variable partiality (partial-access filter): has "St{...}.%something" at the end or "(...).%something"
  2. Variable filter-partiality follows (B)
  3. Full form of specific partiality of Struct Constructor is next: "St {%access1 fld1: val1, %access2 fld2 : val2, ...}". where %access = %permit | %miss | %deny.
  4. Full form of specific partiality of Tuple Constructor is next: "(%access1 fld1: val1, %access2 fld2 : val2, ...)". where %access = %permit | %miss | %deny.
  5. We ad some sugar: If field-access is omitted it means %permit. If field name is omitted (not for Tuples), it field-access mean %miss
  6. We could change %miss field-access into %permit by (let=) operator. var.missed_fld let= val;. So it is both assignment and changing type. Sure, We could simplify and just use (=) instead

(2) Changes in mutability by partiality

  1. Each mutability for variables is supported by partial type extension (Stucts and Tuples) has partiality (partial-mutability): has "mut.%something" at the end
  2. Full form of specific partial mutability is next: "mut.%{%access1 fld1, %access2 fld2, ...}" where "%access = %permit | %deny" and fld - are field names (or number for tuples) with same sugar : if field-access is omitted, it means %permit, if field-name is omitted, it field-access is %deny.
  3. %permit field-mutability mean "mutable" - allow to read, to write, to mutable and immutable.borrowing.
  4. %deny field-mutability mean "immutable"/"const" - allow to read, to immutable.borrowing.
  5. mut.%lift - is a specific mutability - same as mutability in sharing part of type declaration.
  6. we could mixed partiality from type and from mutability together, but we must use &? mut.%type or &? mix = &? mut.%type` in "sharing" part of "type".
  7. Full form of specific --mixed** partiality is next: "St.%{mut? %access1 fld1, mut? %access2 fld2, ...}", if filed is marked as "mut" , this field is mut.%{..., %permit fldN, ...}, if not, then mut.%{..., %deny fldN, ...}.
  8. We add some sugar: if field-mutability is omitted, it means:
  • self.call(& var) ~ self.call(& var)
  • self.call(&mut var) ~ self.call(&mut.%arg var)
  • = .. & var ~ = .. & var
  • = .. &mut var ~ = .. &mut.%max var
  • let var = .. ~ let var = ..
  • let mut var = .. ~ let mut.%full var = ..
  • let mut var : .. = .. ~ let mut.%lift var : .. = ..
  • let .. : &mut Type = .. ~ let .. : &mut.%full Type = ..
  • let .. : &mix Type = .. ~ let .. : &mut.%type Type = ..
  • let .. : mix Type = .. ~ let .. : mut.%type Type = ..

(1 + 2)

  1. combing Partial Types and Partial mutability is simple and do not contradict each other
  • self.call(&mut var) ~ self.call(&mut.%arg var.%arg)
  • = &mut var ~ = &mut.%max var.%max
  • return &mut var ~ = return &mut.%max var.%exact
  • let mut var: mix Type.%{..} = .. ~ let mut.%lift var: mut.%type Type.%{..} = ..

And .... that is all grammar!