Win32 non-backwards compatible API change

[Gauthier Segay]

the reasoning is that user upgrading can easily define that function
which save changing each call site; this makes the breaking change
reasonable to me.

On Fri, Jan 27, 2017 at 6:49 PM, Tamar Christina <tamar at zhox.com> wrote:
>
>  > findWindow lpClassName lpWindowName = WIN32.findWindow (Just
>  > lpClassName) (Just lpWindowName)
>  >
>  > this allow quick fix of code base without changes at call sites (just
>  > one import)
>
> I also thought about providing an old-win32 package which did this, but it wouldn't get
> any further update so I'm not sure it's worth it. Would certainly increase the maintenance.
>
> Most packages have strict version bounds on Win32, (as I found out when updating GHC's shipping version).
>
> So I think for most people they'd have to opt in to this version.
>
>  >
>  > this is unless users are willing to change each call sites, which
>  > shouldn't be too much trouble with help of compiler
>  >
>  >
>  >
>  > On Fri, Jan 27, 2017 at 4:19 PM, Elliot Cameron <eacameron at gmail.com> wrote:
>  > > 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
>  > >
>  > >
>  > > _______________________________________________
>  > > Libraries mailing list
>  > > Libraries at haskell.org
>  > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>  > >
>  >
>  >
>
>
>