-
Notifications
You must be signed in to change notification settings - Fork 0
Remove parameters from (future) .return(…) method #14
Copy link
Copy link
Open
Labels
Change: major[Issue / PR] describes a breaking change of any kind[Issue / PR] describes a breaking change of any kindDomain: main[Issue / PR] describes change in the functionality, its optimization[Issue / PR] describes change in the functionality, its optimizationPending: blocked[Issue / PR] cannot be addressed until another issue is resolved[Issue / PR] cannot be addressed until another issue is resolvedPriority: medium[Issue / PR] should be addressed without delay[Issue / PR] should be addressed without delayType: bug[Issue / PR] addresses malfunction[Issue / PR] addresses malfunction
Description
Metadata
Metadata
Assignees
Labels
Change: major[Issue / PR] describes a breaking change of any kind[Issue / PR] describes a breaking change of any kindDomain: main[Issue / PR] describes change in the functionality, its optimization[Issue / PR] describes change in the functionality, its optimizationPending: blocked[Issue / PR] cannot be addressed until another issue is resolved[Issue / PR] cannot be addressed until another issue is resolvedPriority: medium[Issue / PR] should be addressed without delay[Issue / PR] should be addressed without delayType: bug[Issue / PR] addresses malfunction[Issue / PR] addresses malfunction
Protocol-compliant implementation assumes
.return(…)method having a parameter, that's basically passed through as the return value of the method's call. Sincexrangeis a number iterator, it is designed to return "nothing" (i.e.,undefined) after the iterated range is finished (the currentNaNis temporary as per parzh/xrange#50), which means that the returned value of.return(…)is always an implicitundefined, and it doesn't depend on any inputs.