Backwards Incompatible Changes

[chutcheson]

I was reading through the motivation document and I was really curious:

make backwards-incompatible changes that reflect newer thinking (e.g., structs)

What kinds of backwards-incompatible changes would be beneficial that reflect newer thinking? Also, I'm really curious: what improvements have been made to structs?

[rocketnia]

You might be able to find little examples all over the place in the issue tracker. I'm not sure where to begin. Most Rhombus proposals have a little bit of backwards incompatibility to them in some sense. If they didn't, they could just be Racket proposals.

(To be fair, some of them are long-standing Racket wish list items that people are surfacing as possible out-of-the-gate features for Rhombus. Some of them may be ideas that people proposed for Rhombus first, perhaps having not even thought of suggesting them for Racket. Some of them are synergistic combinations of multiple ideas, which may collectively fall somewhere in between.)

Rhombus is primarily being thought of as a second #lang that would coexist alongside #lang racket. It can be "backwards incompatible" in the sense of harboring a different set of habits, core syntaxes, and terminology than what #lang racket programmers would use, but most ideas people have proposed for Rhombus would cause no breakage to #lang racket programs, and keeping #lang racket usable is an oft-stated goal.

As far as struct goes in particular, these are some of the ideas on people's minds that might culminate in a new meaning of struct in Rhombus:

• Make an RFC about structs lack of hygiene #57
• Make an RFC about unifying structs and classes #76
• Make an RFC about algebraic data / complete matches #89
• Extend notion of scope on behalf of Scribble for things like prop:procedure #92
• Revise the class/object systems to be simpler and more harmonious with structs/generics #152