bug#50214: 28.0.50; cl-struct changes may affect user packages in the wild

[Arthur Miller]

Adam Porter <adam@alphapapa.net> writes:

> Hi,
>
> A helpful user of my ts.el package discovered a change in Emacs 28
> that breaks it:
>
> https://github.com/alphapapa/ts.el/issues/18
>
> Specifically, this commit changes the internal struct constructor from
> a plist to an alist:
>
> https://github.com/emacs-mirror/emacs/commit/3788d2237d4c65b67b95e33d1aca8d8b41780429
>
> For example:
>
> ;; Emacs 28.0.50
> (nth 1 (cl-struct-slot-info 'ts))
> ;;  =>
> ;; (hour
> ;;  nil
> ;;  :type integer
> ;;  (:accessor-init string-to-number
> ;;   (format-time-string
> ;;    "%H"
> ;;    (ts-unix struct)))
> ;;  (:aliases H)
> ;;  (:constructor . "%H"))
>
> ;; Emacs 27.2.50
> (nth 1 (cl-struct-slot-info 'ts))
> ;;  =>
> ;; (hour
> ;;  nil
> ;;  :type integer
> ;;  :accessor-init (string-to-number
> ;;                  (format-time-string
> ;;                   "%H"
> ;;                   (ts-unix struct)))
> ;;  :aliases (H)
> ;;  :constructor "%H")
>
> Unfortunately this breaks how ts.el works.  Of course, that can be
> worked around with a version check, but that means that users who
> upgrade to Emacs 28 without upgrading ts.el will encounter failures.
>
> I don't know if this is something you'd want to reconsider.  I guess
> there was a good reason for the changes being made.  And maybe what
> ts.el is doing is considered unsupported, which would seem like a
> not-unreasonable position.
>
> Anyway, I'm reporting this so the issue is officially documented and
> any decisions can be made accordingly.
>
> Thanks,
> Adam

So what do we learn for the future? Don't use internal representation in your
apps, it is internal for a reason? :)