> It's true that making up new words like "sconnect" is one way to avoid
> ambiguity. But it steepens the learning curve. Another possible convention is
> "mir_connect_now", which is a clear message to the reader that "mir_connect"
> might not connect /right now/.
>
> Separate headers? I disagree. This function relates directly to the existing
> contents of mir_client_library.h. Separate headers would also steepen the
> learning curve and it would be generally bad design to have a "connect"
> function in a different header to its requisite disconnect function.
To clarify: I'm not blocking your approach. Just that I would have defined smir_connect(..) and smir_disconnect(..) and the rest of a synchronous API in a separate and independent header.
> It's true that making up new words like "sconnect" is one way to avoid library. h. Separate headers would also steepen the
> ambiguity. But it steepens the learning curve. Another possible convention is
> "mir_connect_now", which is a clear message to the reader that "mir_connect"
> might not connect /right now/.
>
> Separate headers? I disagree. This function relates directly to the existing
> contents of mir_client_
> learning curve and it would be generally bad design to have a "connect"
> function in a different header to its requisite disconnect function.
To clarify: I'm not blocking your approach. Just that I would have defined smir_connect(..) and smir_disconnect(..) and the rest of a synchronous API in a separate and independent header.