Skip to content

Add open question about partial constructors in top-level statements #9085

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.

Sign up for GitHub

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

Merged
jjonescz merged 1 commit into from
Jan 23, 2025
Merged

Add open question about partial constructors in top-level statements #9085

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 2 additions & 0 deletions meetings/2025/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,8 @@ All schedule items must have a public issue or checked-in proposal that can be l

## Schedule ASAP

- [Partial constructors open question](../../proposals/partial-events-and-constructors.md#break-in-top-level-contexts) (Jan)

## Schedule when convenient

- Triage (working set)
Expand Down
13 changes: 13 additions & 0 deletions proposals/partial-events-and-constructors.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -243,6 +243,19 @@ We propose the first two member kinds, but any other subset could be considered.
Partial *primary* constructors could be also considered,
e.g., permitting the user to have the same parameter list on multiple partial type declarations.

### Break in top-level contexts

Constructors cannot be defined in top-level statements or scripts, i.e., the following is legal today:

```cs
System.Console.Write(F().GetType().Name); // prints "partial"
partial F() => new();
class @partial;
```

Do we want to keep this behavior or can we break here and simplify the parser?
If we break, the workaround for users is to use `@partial` for the return type of the method as well.
Copy link
Member

@CyrusNajmabadi CyrusNajmabadi Jan 23, 2025

Choose a reason for hiding this comment

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

Note: searching github, i don't see any hits for partial identifier(. So it seems unlikely that peopel are doing this. Similar to how we've carved out other identifiers and stated we will only interpret them as a modifier and not a type (record, scoped, etc.) this feels very much in line with going the same route.

Esp. given no matches in the wild, this seems safe and sane.

Copy link
Member

@RikkiGibson RikkiGibson Jan 23, 2025

Choose a reason for hiding this comment

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

Also, there is a little while until next LDM, perhaps we should float this question by email.

Copy link
Member

@CyrusNajmabadi CyrusNajmabadi Jan 23, 2025

Choose a reason for hiding this comment

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

i would be fine with email :) @jjonescz do you want to send?


<!--------
## Links
--------->
Expand Down