#4842: keep Data.Map.foldWithKey
---------------------------------+------------------------------------------
    Reporter:  maeder            |       Owner:                   
        Type:  proposal          |      Status:  new              
    Priority:  normal            |   Component:  libraries (other)
     Version:  7.0.1             |    Keywords:                   
    Testcase:                    |   Blockedby:                   
          Os:  Unknown/Multiple  |    Blocking:                   
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown     
---------------------------------+------------------------------------------
 Remove the recently introduced deprecation warning for
 `Data.Map.foldWithKey` as the aim to finally remove this function is bad
 as long as `Data.IntMap.foldWithKey` is the primary folding function for
 the specialized maps.

 The deprecation was introduced by
 http://hackage.haskell.org/trac/ghc/ticket/4277 that also added
 `foldlWithKey` and `foldrWithKey`.

 But at least as long as these functions are not exported also by
 `Data.IntMap`, as proposed by
 http://hackage.haskell.org/trac/ghc/ticket/3999, the common name
 `foldWithKey` should be kept. Such a common name is also used for the
 simple "fold" functions over maps and sets.

 There was already some disagreement on this point in the thread
 http://www.haskell.org/pipermail/libraries/2010-December/015274.html which
 convinced me to create this proposal.

 I think two weeks of discussion should be enough, but I'll be happy about
 a decision by mid January 2011.

 The change is almost only cosmetic, delete:

 {{{
 {-# DEPRECATED foldWithKey "Use foldrWithKey instead" #-}
 }}}

 and change "should" to "may" in the documentation:
 {{{
 -- This is identical to 'foldrWithKey', and you should use that one
 instead of
 -- this one.  This name is kept for backward compatibility.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4842>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to