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

Basic classes: use cases, struct literals, struct types, and future work #561

Merged
merged 83 commits into from
Aug 9, 2021
Merged
Changes from 1 commit
Commits
Show all changes
83 commits
Select commit Hold shift + click to select a range
f4a7568
Filling out template with PR 561
josh11b Jun 2, 2021
ed189a9
Fill in proposal template
josh11b Jun 3, 2021
f03e0d6
Checkpoint progress.
josh11b Jun 3, 2021
815ee7b
Filling out template with PR 561
josh11b Jun 2, 2021
2c26238
Fill in proposal template
josh11b Jun 3, 2021
5304872
Checkpoint progress.
josh11b Jun 3, 2021
e914354
Update README.
josh11b Jun 3, 2021
cd5b3c2
Merge remote-tracking branch 'refs/remotes/origin/structs-2' into str…
josh11b Jun 3, 2021
7e3933b
Checkpoint progress.
josh11b Jun 3, 2021
4babbcb
Checkpoint progress.
josh11b Jun 4, 2021
5b441c8
Filling out template with PR 561
josh11b Jun 2, 2021
6239f7a
Fill in proposal template
josh11b Jun 3, 2021
12e08df
Checkpoint progress.
josh11b Jun 3, 2021
4895b04
Update README.
josh11b Jun 3, 2021
aa48975
Checkpoint progress.
josh11b Jun 3, 2021
ff68585
Checkpoint progress.
josh11b Jun 4, 2021
c544b0a
Merge branch 'structs-2' of github.com:josh11b/carbon-lang into struc…
josh11b Jun 22, 2021
e9827b3
Iterate on use case text.
josh11b Jun 22, 2021
ba73b43
Checkpoint progress.
josh11b Jun 25, 2021
a5ac27f
Checkpoint progress.
josh11b Jun 25, 2021
25cf0b7
Use cases are in pretty good shape now.
josh11b Jun 25, 2021
7869741
Checkpoint progress.
josh11b Jun 25, 2021
8972a40
First complete version.
josh11b Jun 26, 2021
a703cbd
Checkpoint progress.
josh11b Jun 26, 2021
303fcd5
Merge remote-tracking branch 'upstream/trunk' into structs-2
josh11b Jun 26, 2021
dae391f
Replace "parent/child" with "base/derived type".
josh11b Jun 28, 2021
3a58e7f
Further fix terminology.
josh11b Jun 28, 2021
21a9923
Apply suggestions from code review
josh11b Jun 28, 2021
65b0d39
Use "anonymous" and "nominal" instead of "(un)named"
josh11b Jun 28, 2021
34fd7ba
Better rationale for distinct syntax for types.
josh11b Jun 28, 2021
ca48a17
Address syntax ambiguity of `{`
josh11b Jun 29, 2021
6f94997
Add non-virtual inheritance, TODOs, clarification
josh11b Jun 30, 2021
bd34505
Rename "data type" to "data class"
josh11b Jun 30, 2021
09679f3
Fix formatting and linking.
josh11b Jun 30, 2021
da2d0f8
Difference and overlap between ABC and polymorphic types.
josh11b Jun 30, 2021
13f4f2d
Clarify polymorphic types based on review
josh11b Jun 30, 2021
96bb407
May support ABCs long term
josh11b Jun 30, 2021
2703122
New name for ABCs?
josh11b Jul 1, 2021
b2b2314
Resolution of #494 and `alias`->`let`
josh11b Jul 7, 2021
a7d6fbb
Questions about `let`
josh11b Jul 7, 2021
6e161e9
Part way through redoing use cases
josh11b Jul 14, 2021
4690658
Checkpoint progress.
josh11b Jul 14, 2021
48181d5
Checkpoint progress.
josh11b Jul 15, 2021
2b56c8a
Checkpoint progress.
josh11b Jul 16, 2021
f36ce10
Apply suggestions from code review
josh11b Jul 20, 2021
5cb3318
Apply suggestions from code review
josh11b Jul 20, 2021
8dd821f
Fix line breaks
josh11b Jul 20, 2021
aa0bad5
Incorporate suggestion
josh11b Jul 20, 2021
85cbed7
Big fixes to use cases, add computed properties
josh11b Jul 23, 2021
46ae873
Updates to the last half
josh11b Jul 23, 2021
86941fa
Anonymous type declarations are really just type expressions
josh11b Jul 23, 2021
4be36a1
Implementing interfaces for data classes
josh11b Jul 23, 2021
f0ac344
Expand alternatives considered
josh11b Jul 23, 2021
e4e83d5
Open questions about assign and init
josh11b Jul 24, 2021
2dd640c
Merge remote-tracking branch 'upstream/trunk' into structs-2
josh11b Jul 24, 2021
7cbb93b
Updates
josh11b Jul 24, 2021
201649a
Mixin open questions
josh11b Jul 28, 2021
1fe6d52
Answer an open question
josh11b Jul 28, 2021
d3c6590
Tuples act like data classes for blanket interface impl
josh11b Jul 30, 2021
3e3b6e4
Include resolution of issues #651 and #653
josh11b Jul 30, 2021
7f5abad
`struct` -> `class` in README
josh11b Jul 30, 2021
c856bee
Rename structs.md to classes.md
josh11b Jul 30, 2021
9f7cf2b
struct -> class
josh11b Jul 30, 2021
ccf0f4d
struct -> class in proposal
josh11b Jul 30, 2021
bb3abb8
Clarify that struct types are a subset of data class types
josh11b Jul 30, 2021
0d0aa69
struct -> class in generics design docs
josh11b Jul 30, 2021
2c4e1d5
Fix old `struct` refs, `struct` is not a keyword
josh11b Aug 1, 2021
79794d2
Use for properties from KateGregory
josh11b Aug 3, 2021
f865d76
Apply suggestions from code review
josh11b Aug 3, 2021
2477335
Fix formatting
josh11b Aug 3, 2021
0939ce3
Update problem statement in proposal
josh11b Aug 3, 2021
80eb33c
Match `impl` syntax from #575.
josh11b Aug 3, 2021
0913cbd
"class" instead of "`class`"
josh11b Aug 4, 2021
f66dbfa
Small fixes to "access control" alternatives
josh11b Aug 5, 2021
3543e28
Apply suggestions from code review
josh11b Aug 5, 2021
dc1e48f
Comparisons question is now #710.
josh11b Aug 5, 2021
95c9aa5
Merge branch 'trunk' into structs-2
josh11b Aug 5, 2021
0dc39ea
Fix formatting
josh11b Aug 5, 2021
eae9b5e
Move struct field defaults and option parameters to future work
josh11b Aug 6, 2021
7e04407
Allow trailing comma
josh11b Aug 7, 2021
68720ec
Update docs/design/classes.md
josh11b Aug 7, 2021
ff1c37b
Empty `{}` case, fix formatting
josh11b Aug 7, 2021
85587dc
No `{,}`
josh11b Aug 8, 2021
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Checkpoint progress.
josh11b committed Jun 4, 2021
commit 4babbcbcacd5283d593ea489d97403fc5a364053
72 changes: 58 additions & 14 deletions docs/design/structs.md
Original file line number Diff line number Diff line change
@@ -15,6 +15,8 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
- [Data types](#data-types)
- [Object types](#object-types)
- [Polymorphic types](#polymorphic-types)
- [Abstract base classes](#abstract-base-classes)
- [Other cases](#other-cases)
- [Background](#background)
- [Overview](#overview-1)
- [Fields have an order](#fields-have-an-order)
@@ -29,7 +31,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
- [Alias](#alias)
- [Future work](#future-work)
- [Method syntax](#method-syntax)
- [Constant members](#constant-members)
- [Destructuring, pattern matching, and extract](#destructuring-pattern-matching-and-extract)
- [Access control](#access-control)
- [Operator overloading](#operator-overloading)
- [Inheritance](#inheritance)
@@ -60,7 +62,7 @@ types, and polymorphic types.

### Data types
Copy link
Contributor

Choose a reason for hiding this comment

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

This term has a pre-existing meaning in common use that's very different from the definition here (e.g. try asking a programmer whether Int and String are data types), so I think we're going to need to coin a new term for this. "Plain struct types", maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've renamed to "data classes" based on the usage in Kotlin and Python.


Characterized by: public data fields, few if any methods.
Characterized by: public data fields, few if any methods, final.

Example: Key and value pair returned from a `SortedMap` or `HashMap`.

@@ -72,7 +74,7 @@ FIXME

FIXME

Characterized by: private data fields, non-overridable methods.
Characterized by: private data fields, non-overridable methods, final.

Examples: strings, containers, iterators, types with invariants like `Date`

@@ -82,16 +84,50 @@ Include:
a file handle
- non-movable types like `Mutex`

Extending this design to support object types is future work.

FIXME: public API and private helper API

### Polymorphic types

Characterized by: inheritance, private data in a base type, overridable/virtual
methods with dynamic dispatch, accessed through a pointer to "type extending
base"

Excluding complex multiple inheritance schemes, virtual inheritance, etc.
Excluding complex multiple inheritance schemes, virtual inheritance, etc. One
base class for purposes of subtyping. Can have other parents as "mixins".

FIXME: Talk about the external API versus the APIs for communicating between
base and derived.

FIXME

Extending this design to support polymorphic types is future work.

### Abstract base classes

Can we use interfaces as the model for C++ ABCs to support implementing
multiple? Can we skip supporting derived-to-base conversions in this case?

How do you pass something implementing this from Carbon to C++?

Maybe we can say: you can inherit from multiple base classes but only the first
can have any data?

### Other cases

inheritance without virtual: intrusive linked list, need to be able to get from
the intrusive linked list type to the main type; type can be part of another
inheritance hierarchy. Could be handled in Carbon by giving mix-ins the
capability to go from their pointer to the pointer to the containing object.

iostream, virtual multiple inheritance, and base class has state; some uses of
streams are ifstream, ofstream; hard cases are the bidirectional ones: fstream,
stringstream. very few uses of fstream; one quarter are ostringstream, most
could be.

Do we want to expose Carbon interfaces to C++ as ABCs?

## Background

See how other languages tackle this problem:
@@ -253,24 +289,29 @@ We will need some way of defining methods on structs. The big concern is how we
designate the different ways the receiver can be passed into the method. This
question is being tracked in
[question-for-leads issue #494](https://github.com/carbon-language/carbon-lang/issues/494).
As an example, we need some way to distinguish methods that don't take a
receiver at all, like
[C++'s static methods](<https://en.wikipedia.org/wiki/Static_(keyword)#Static_method>)

### Constant members
We do not expect to have implicit member access in methods.

We need some syntax for defining constant members beyond
[member types](#member-type). These include:
### Destructuring, pattern matching, and extract

- Constant member values, like C++'s `std::string::npos`
- Functions that don't take a receiver, like
[C++'s static methods](<https://en.wikipedia.org/wiki/Static_(keyword)#Static_method>)

All of these may be accessed as members of the type itself, without a value of
that type.
FIXME

### Access control

We will need some way of controlling access to the members of structs. For now,
we assume all members are fully publicly accessible.

The default access control level, and the options for access control, are pretty
large open questions. Swift and C++ (especially w/ modules) provide a lot of
options and a pretty wide space to explore here. If the default isn't right most
of the time, access control runs the risk of becoming a significant ceremony
burden that we may want to alleviate with grouped access regions instead of
per-entity specifiers. Grouped access regions have some other advantages in
terms of pulling the public interface into a specific area of the type.

### Operator overloading

This includes destructors, copy and move operations, as well as other Carbon
@@ -280,7 +321,10 @@ implementing corresponding interfaces, see

### Inheritance

FIXME: no multiple inheritance
FIXME: limited multiple inheritance

FIXME:
[doc with constructor options for inheritance](https://docs.google.com/document/d/1GyrBIFyUbuLJGItmTAYUf9sqSDQjry_kjZKm5INl-84/edit)

### Memory layout