TList requests

We should have list.first() simply return null on an empty list instead of erroring.

Also:
Can ListRemove return the success state? Return 1 if successful, and 0 if the object was not found to be in the list.

I vote no
If you are worried about it cheack yourself before you use it with ListIsempty
All that you would be doing by moving it into list.first is adding an overhead of an impossed call to listisempty

I agree with H&K, the functionality is already there. Why force it upon everyone? There will be times when you check the list isn't empty once and then make several references to list.first(). There's no need to check every single time you call, but if this was added, you wouldn't have any choice in the matter.

Same with ListRemove(). If you want to know if it's there, call List.Contains() before removing and you'll know.

If you were requesting something that you couldn't already do, I'd say fair enough, but I don't want it slowing down all my code when what you want is already there.

Here's the current code for list.first(). The IsEmpty() call is already there.

I don't want to slow down anyone's code. I definately want some improvements built-in.

	Method First:Object()
		Assert Not IsEmpty() Else "Illegal operation on empty list"
		Return _head._succ._value
	End Method

About ListRemove:
list.remove already returns the success state. I think it's just a mistake that ListRemove doesn't.

Assert's only happen in debug mode, so the IsEmpty() call is not already there.

Ah that's what that command is for! That really needs to be added to Assert's doc.

In that case, you're probably correcr that it's just an oversight. I don't guess there's much difference between returning or not returning, is there? I mean, it has to look in order to attempt to remove, so I guess it's no odds either way.

I am amazed about assert