Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More language guide edits #10

Merged
merged 2 commits into from
Jul 27, 2022
Merged

More language guide edits #10

merged 2 commits into from
Jul 27, 2022

Conversation

dabrahams
Copy link
Contributor

No description provided.

@dabrahams dabrahams requested a review from kyouko-taiga July 25, 2022 14:40
implications. In particular, it means you can't simply add/remove stored properties, even if they
were non-public, without breaking client code. I'd like to design some facilities for helping a
library author to ensure API stability eventually.
{% endcomment %}
Copy link
Contributor

@kyouko-taiga kyouko-taiga Jul 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that.

The idea is that if you want to change the layout of the type later on, you'll have to write a custom initializer to keep your promise. That's what you have to do in Swift today anyway. The memberwise init feature is just a shortcut for a large class of situations where your type does not cross a resilience boundary but also doesn't want to expose all its parts publicly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! But the problem in Swift today is that AFAIK there's nothing in place to discourage you from changing the layout of your type once you've made the promise. Actually in the case of API it's not necessarily about layout, just about which members are stored.


*Note: Though Val should not be considered a functional programming language, it does support this style of programming relatively well, as functions are first-class citizen.*
*Note: Though Val should not be considered a functional programming language, functions are
first-class citizens, and functional programming style is well-supported. In fact, Val's mutable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@dabrahams dabrahams merged commit 70e256a into main Jul 27, 2022
@dabrahams dabrahams deleted the language-guide-edits branch July 27, 2022 16:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants