Ticket #0001626

Type	Wish	Status	complete	Date	30-Jun-2010 06:26
Version	alpha 99	Category	Native	Submitted by	BrianH
Platform	All	Severity	minor	Priority	normal

Summary	Allow LENGTH? to take none as an argument, return none
Description	The same argument that was put forth to make EMPTY? take the none argument could apply to LENGTH? as well: LENGTH? none could return none. The advantage would be to simplify the use of LENGTH? in code patterns like those shown below. See http://www.rebol.net/r3blogs/0315.html for EMPTY? none and #1611 for INDEX? none.
Example code	; Desired behavior >> length? none == none ; Instead of this b: either b: find series var [length? b] [default] ; I can then do this b: any [length? find series var default]

Assigned to	n/a	Fixed in	alpha 108	Last Update	2-Nov-2010 03:44

Comments
(0002409) BrianH 30-Jun-2010 06:26	The disadvantage to this is that LENGTH? would occasionally return none, rather than always an integer (no, don't change the proposal to return anything other than none, it's the only sensible return value in this case). This means that code that needs to rely on integer data being there would have to check for that. This is not a big problem in R3 though because we can use ASSERT, or code like the EITHER example code. So its either a function that forces you to use code like the EITHER pattern above all the time, or a function that only requires you to use it where appropriate but also requires you to remember this. The community's answer to the EMPTY? none question is probably a good guideline to follow: We prefer flexibility in R3, even if it can count as a gotcha, and can check things ourselves if we need to.
(0002748) abolka 2-Nov-2010 03:27	In the core-tests suite.

Comments

(0002409)
BrianH
30-Jun-2010 06:26

The disadvantage to this is that LENGTH? would occasionally return none, rather than always an integer (no, don't change the proposal to return anything other than none, it's the only sensible return value in this case). This means that code that needs to rely on integer data being there would have to check for that. This is not a big problem in R3 though because we can use ASSERT, or code like the EITHER example code.

So its either a function that forces you to use code like the EITHER pattern above all the time, or a function that only requires you to use it where appropriate but also requires you to *remember* this. The community's answer to the EMPTY? none question is probably a good guideline to follow: We prefer flexibility in R3, even if it can count as a gotcha, and can check things ourselves if we need to.

(0002748)
abolka
2-Nov-2010 03:27

In the core-tests suite.

Date	User	Field	Action	Change
2-Nov-2010 03:44	BrianH	Code	Modified	-
2-Nov-2010 03:44	BrianH	Status	Modified	tested => complete
2-Nov-2010 03:27	abolka	Comment : 0002748	Added	-
20-Oct-2010 03:54	BrianH	Status	Modified	built => tested
21-Sep-2010 19:49	carl	Fixedin	Modified	=> alpha 108
21-Sep-2010 19:49	carl	Status	Modified	reviewed => built
30-Jun-2010 06:27	BrianH	Description	Modified	-
30-Jun-2010 06:27	BrianH	Code	Modified	-
30-Jun-2010 06:27	BrianH	Status	Modified	submitted => reviewed
30-Jun-2010 06:26	BrianH	Comment : 0002409	Added	-
30-Jun-2010 06:26	BrianH	Ticket	Added	-