Ticket #96 (reopened defect)

Opened 2 years ago

Last modified 1 year ago

Resolved) Allowable types for the rest argument

Reported by: cormac Assigned to: anonymous
Type: defect Priority: trivial
Milestone: M2 Component: Spec
Version: 4 Keywords:
Cc: lth, graydon, jeffdyer, dherman, brendan

Description (last modified by cormac) (diff)

-- Should we support function types such as: function(int,int=,...[int,int]):int where the rest args requires a third integer, so the default argument is meaningless. One solution is to only allow array types with one element (ie a "zero-or-more" length array) as the type (if any) of the rest arg.

Attachments

Change History

Changed 2 years ago by cormac

  • description changed from Object or {} denotes the empty object, which is distinct from the dynamic object {*}. However, Array or [] denotes the dynamically-typed array, which is equivalent to [*]. Although not a bug per se, there is a certain lack of symmetry here. to A multi-part ticket on some type system issues: -- Object or {} denotes the empty object, which is distinct from the dynamic object {*}. However, Array or [] denotes the dynamically-typed array, which is equivalent to [*]. Although not a bug per se, there is a certain lack of symmetry here. -- Should we support function types such as: function(int,int=,...[int,int]):int where the rest args requires a third integer, so the default argument is meaningless. One solution is to only allow array types with one element (ie a "zero-or-more" length array) as the type (if any) of the rest arg.
  • summary changed from Array vs Object to Type Issues

Changed 2 years ago by cormac

  • description changed from A multi-part ticket on some type system issues: -- Object or {} denotes the empty object, which is distinct from the dynamic object {*}. However, Array or [] denotes the dynamically-typed array, which is equivalent to [*]. Although not a bug per se, there is a certain lack of symmetry here. -- Should we support function types such as: function(int,int=,...[int,int]):int where the rest args requires a third integer, so the default argument is meaningless. One solution is to only allow array types with one element (ie a "zero-or-more" length array) as the type (if any) of the rest arg. to A multi-part ticket on some type system issues: -- Object or {} denotes the empty object, which is distinct from the dynamic object {*}. However, Array or [] denotes the dynamically-typed array, which is equivalent to [*]. Although not a bug per se, there is a certain lack of symmetry here. -- Should we support function types such as: function(int,int=,...[int,int]):int where the rest args requires a third integer, so the default argument is meaningless. One solution is to only allow array types with one element (ie a "zero-or-more" length array) as the type (if any) of the rest arg.

Changed 2 years ago by brendan

  • cc set to lth, graydon, jeffdyer, dherman, brendan

It would be good to keep Object === {} and Array === [], but we would want some teeth in the empty-array-type. This depends on the Array bound proposal, cc'ing lth.

It makes sense to allow optional and rest parameter combinations, which implies that f(int,int=,...[int,int]) should be an error. When preceded by an optional parameter, the rest parameter type must an array type of zero-or-more element types.

/be

Changed 1 year ago by cormac

  • status changed from new to closed
  • resolution set to fixed

Resolved that in a type

function(int,int=,...T):int

that T must be an array type supporting zero-or-more elements.

Changed 1 year ago by brendan

  • status changed from closed to reopened
  • resolution deleted

Usual course is to change the ticket's component to RefImpl? from Proposals and then patch the mtn repository to implement the spec. Reopening but not taking.

/be

Changed 1 year ago by brendan

  • component changed from Proposals to RefImpl

Changed 1 year ago by cormac

  • component changed from RefImpl to Proposals
  • description changed from A multi-part ticket on some type system issues: -- Object or {} denotes the empty object, which is distinct from the dynamic object {*}. However, Array or [] denotes the dynamically-typed array, which is equivalent to [*]. Although not a bug per se, there is a certain lack of symmetry here. -- Should we support function types such as: function(int,int=,...[int,int]):int where the rest args requires a third integer, so the default argument is meaningless. One solution is to only allow array types with one element (ie a "zero-or-more" length array) as the type (if any) of the rest arg. to -- Should we support function types such as: function(int,int=,...[int,int]):int where the rest args requires a third integer, so the default argument is meaningless. One solution is to only allow array types with one element (ie a "zero-or-more" length array) as the type (if any) of the rest arg.

On July 10 meeting, we resolved that in a type

function(int,int=,...T):int

that T must be an array type supporting zero-or-more elements.

It would simplify things somewhat to say that T must *always* an array type supporting zero-or-more elements - and there seems to be no loss of expressive power, since we can always add more regular arguments.

Changed 1 year ago by cormac

  • description changed from -- Should we support function types such as: function(int,int=,...[int,int]):int where the rest args requires a third integer, so the default argument is meaningless. One solution is to only allow array types with one element (ie a "zero-or-more" length array) as the type (if any) of the rest arg. to -- Should we support function types such as: function(int,int=,...[int,int]):int where the rest args requires a third integer, so the default argument is meaningless. One solution is to only allow array types with one element (ie a "zero-or-more" length array) as the type (if any) of the rest arg.

Changed 1 year ago by cormac

  • component changed from Proposals to Spec

We will allow "function(int=,...[int])" and "function(int=,...Array)" (the default if missing type annotation on rest arg) but will disallow "function(...[int,int])".

Changed 1 year ago by lth

  • priority changed from major to trivial
  • summary changed from Type Issues to Resolved) Allowable types for the rest argument
Note: See TracTickets for help on using tickets.