std.socket classes

[rikki cattermole via Digitalmars-d-learn]

On 09/04/2017 3:56 PM, Jonathan Marler wrote:
> On Sunday, 9 April 2017 at 14:49:14 UTC, rikki cattermole wrote:
>> Don't think too hard, times have changed since std.socket was written.
>> It certainly isn't designed for high performance hence e.g. libasync.
>
> What an odd response... You don't think I should ask questions about why
> decisions were made?  If I took that approach how would I learn?  And if
> you discourage other people from asking questions by telling them they
> are "thinking too hard" what kind of effect does that have on the
> community?
>
> As for "high performance", my questions have less to do with performance
> than they do with an API that makes sense and doesn't feel "kludgy".

Oh sorry, I had a brain derp and thought at the end there you had that 
you thought about it and it didn't make sense. Hence the slightly 
weirder response.

What I meant is that, for common use cases it works well enough and it 
does use reasonably sound API even if a bit cludgy.

When asking about classes, one of the big things is the vtable. They are 
slow (compared to final classes and structs). This is the main reason 
people want to switch over to structs instead of classes. However if you 
take a look at the more performance aware libraries like libasync you 
will see classes used extensively still.

Here is my suggestion, its a little harder to toy with ideas without 
real code to show for it. All our more existing API's are mostly class 
based for high performance sockets, timers ext. So, would you like to 
have a go and explore this area since we are playing it a bit too safe 
for your liking?