[fpc-pascal] why connect is "deprecated"

[Marco van de Voort]

In our previous episode, Jonas Maebe said:
> > sb
> > wants to support and modernize them, I have no problem with that.  
> > But that
> > hasn't happened since 2005-2007 or so.

The modernize bit above also refers to the changes done during the 2.0 RTL 
update, the functions still have a 1.0.x signature:

- Name (fp-)
- parameter typing
- parameter returnvalue. IOW return a proper -1

Besides that the Unix socket unit has extra overload versions
which are used in the examples, which means that the examples
only work on *nix. 

> What needs to be modernised about it?
> It's not like our disk i/o error  
> code handles many more different error codes, nor are those errors  
> much more specific

There are specific disk related error codes defined. Not for sockets. IIRC
there is no way to distinguish between a clean disconnect and an unexpected
error. The information is lost, since the error is cached nowhere.

Attempts with non-blocking sockets will block unless fpread returns ewouldblock
and ewouldblock<>eagain

The above is a bit grasping at straws from memory(the attempts below) and a
quick look.  The problem IMHO is more that nobody knows.

> I remember the old discussion, but I never understood how the error
> reporting of the sockets code and the generic I/O code differed in a way
> that made the former worse than the latter.

>From what I remember, several people tried to create a simple chat server
example with it (when Ales was starting out with lnet), and failed
miserably.  That is the only serious attempt at every doing something with
these that I know.

If I'm honest, they were experimenting with non-blocking sockets too though,
so that might have confused the picture though.

Btw the number of reactions to the deprecation has been mostly zero.

> > That would also make it possible to directly map socketerror to
> > getlastresult/fpgeterrno, instead of caching it in another threadvar.
> 
> IIRC the problem with removing socketerror would be that it could  
> easily break existing code (given that socketerror is not overwritten  
> by calls other than those from the sockets unit).

True. And that behaviour was never deprecated because "socketerror" was
considered needed to abstract socket errors in an OS dependent manner when
sockets also was expanded to be supported on Windows.

I never considered the proper deprecation way (deprecating socketerror,
introducing a new function) worth the trouble, specially since the number
of users with such code are probably extremely low (since all pre 1.0.x
functions that rely on it are removed or deprecated, oldlinux isn't compiled
anymore etc)

I always assume these functions would either be removed or moved and
updated anyway.