Win32 non-backwards compatible API change

Elliot Cameron eacameron at gmail.com
Fri Jan 27 15:19:40 UTC 2017


As painful as the transition might be, we desperately need to set this
right sooner rather than later. The number of libraries depending on win32
is not going to decrease over time.

+1

On Jan 27, 2017 7:54 AM, "Tamar Christina" <tamar at zhox.com> wrote:

> Hi All,
>
> I want to revive and push forward a change first proposed in 2014 for an
> API
> change in the Win32 package.
>
> The discussion at that time took place here https://github.com/haskell/
> win32/issues/24
>
> In short, In the Windows API it is common that when a function accepts a
> pointer to something,
> that NULL also be valid and defaults to some action. Such an example is
> the FindWindow call.
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/
> ms633499(v=vs.85).aspx
>
> HWND WINAPI FindWindow(
>   _In_opt_ LPCTSTR lpClassName,
>   _In_opt_ LPCTSTR lpWindowName
> );
>
> In this case, both the ClassName and the WindowName are allowed to be NULL.
>
> The Haskell binding to this function is findWindow :: String -> String ->
> IO (Maybe HWND).
> So we've lost the ability to use the default parameters.
>
> The proposal is to change such functions to accept Maybe:
>
> findWindow :: String -> String -> IO (Maybe HWND)
>
> becomes
>
> findWindow :: Maybe String -> Maybe String -> IO (Maybe HWND)
>
> Which also would more accurately match the original API. This is of course
> a backwards incompatible change.
>
> Any objections to this change?
>
> Thanks,
> Tamar
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170127/696f8cea/attachment.html>


More information about the Libraries mailing list