Re: [GHC] #14347: Top-level RecordWildCards no longer working.

12 Oct 2017

      #14347: Top-level RecordWildCards no longer working.
-------------------------------------+-------------------------------------
        Reporter:  Fuuzetsu          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by RyanGlScott):

 * cc: adamgundry (removed)
 * cc: simonpj (added)

Comment:

 Oh, it turns out this breakage was intentional! It was caused by commit
 2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd:

 {{{
 From 2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd Mon Sep 17 00:00:00 2001
 From: Simon Peyton Jones 
 Date: Thu, 23 Jun 2016 09:02:00 +0100
 Subject: [PATCH] Narrow the use of record wildcards slightly

 In reviewing the fix to Trac #12130 I found the wild-card
 fill-in code for ".." notation in record constructions hard
 to understand.  It went to great contortions (including the
 find_tycon code) to allow
     data T = C { x, y :: Int }
     f x = C { .. }
 to expand to
     f x = C { x = x, y = y }
 where 'y' is an /imported function/!  That seems way over the top
 for what record wildcards are supposed to do.

 So I have narrowed the record-wildcard expansion to include only
 /locally-bound/ variables; i.e. not top level, and certainly not
 imported.

 I don't think anyone is using record wildcards in this bizarre way, so
 I don't expect any fallout. Even if there is, you can easily
 initialise fields with eponymous but imported values by hand.

 An intermediate position would be to allow /local/ top-level
 definitions.  But I doubt anyone is doing that either.

 Let's see if there's any fallout.  It's a local change, easy to
 revert, so I've just gone ahead to save everyone's time.
 }}}

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14347#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler