Proposal to deprecate and then drop fromJust

[Edward Kmett]

-1

I'm personally pretty strongly against removing this function on mere
proscriptive grounds and a deprecation is effectively removal for most
users who care about warnings.

I wouldn't have voted to add it in the first place, but now that it is here
and in wide use asking several thousand occurrences on hackage to change to
suit your sensibilities and use more verbose alternatives seems to be
rather brutal.

That said, I'd fully support putting in strong wording in the documentation
about the partial nature of the function.

-Edward




On Tue, Feb 24, 2015 at 2:07 PM, Chris Allen <cma at bitemyapp.com> wrote:

>  However, I think it'll require a very long deprecation cycle before
> actually removing it from base, as 'fromJust' is officially part of
> Haskell 2010, and there's probably a lot of code out there using
> 'fromJust'...
>
> Terrifyingly, yes. I fired off a shell-script to cabal unpack all the
> libraries on Hackage last night and some cursory grepping has brought me:
>
> 1,176 instances of where fromJust is explicitly imported from Data.Maybe
> 7,431 instances of fromJust mentioned in a Haskell source file
>
> I'm in favour (+1) of the deprecation (warnings) cycle proposal kicked
> around.
>
> Also if anyone knows of a semantically aware (ie, can distinguish
> functions, imports, etc.) open source code search tool, I'd be very
> grateful if they'd point me in that direction.
>
>
>
> On 02/24/2015 04:54 AM, Michael Snoyman wrote:
>
>
>
> On Tue Feb 24 2015 at 12:47:07 PM Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
>> On 2015-02-24 at 06:42:22 +0100, Erik de Castro Lopo wrote:
>> > We currently have in the Data.Maybe module from base:
>> >
>> >      fromJust :: Maybe a -> a
>> >
>> > which newbies often find using hoogle or other search tools and is
>> > a huge trap. *Every* usage of the above can be replaced by using
>> >
>> >       fromMaybe :: a -> Maybe a -> a
>> >
>> > which forces the user to provide a default value for the case where
>> > the Maybe a is a Nothing.
>> >
>> > The idea would be to deprecate fromMaybe for 7.12 and remove it
>> > completely later.
>>
>> I'm +1 for deprecating (or attach a warning pragma to) 'fromJust' as
>> I've been bit by 'fromJust' myself in the past, when I was still mixing
>> up 'fromMaybe' and 'fromJust'. Nowadays I don't reach out for 'fromJust'
>> anymore at all.
>>
>> However, I think it'll require a very long deprecation cycle before
>> actually removing it from base, as 'fromJust' is officially part of
>> Haskell 2010, and there's probably a lot of code out there using
>> 'fromJust'...
>>
>> Relatedly, I was thinking of a separate 'partial-functions' warning
>> class, so we could annotate partial functions (head/last/...) in base,
>> and have the associated warnings be tunable via a separate GHC -fwarn*
>> flag. This could even be generalised to arbitrary warning-classes:
>>
>>  {-# WARNING[partial] fromJust "Use 'fromMaybe' instead" #-}
>>
>> I'm sure we would come up with other useful warning-classes...
>>
>>
>>
>  This sounds like a great idea, which I'd support fully. The idea of
> letting people opt-out of partiality warnings somehow would IMO address the
> concerns here perfectly.
>
>  Even though I'm strongly opposed to fromJust, I'm -1 on removing it any
> time soon due to ensuing breakage. I'm on the fence with a standard
> deprecation warning (since by what I just said we really *aren't*
> deprecating it), but a WARNING would be great.
>
>  Michael
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> 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/20150224/5ff4e68d/attachment-0001.html>