An incomplete, early, and in-progress overview of the language design. #22

chandlerc · 2020-05-21T07:19:52Z

This is basically a snapshot of an in-progress document, moved to
markdown and prepared for sharing with the wider community. It isn't
finished. It isn't even ready for full review yet. Some specific changes
that I'm planning to make:

I want to reorganize the sections of the document a bit. The current
structure is somewhat outdated and I have better ideas about how to
organize these things.
Some of the sections are quite old and don't come close to current
thinking. While to an extent this is inevitable, I'd like to clean at
least a few of them up.

However, as is I think it still provides a starting point and gives
people the feel of what this will look like.

There are a number of document links lost in this conversion. I've
carefully left a TODO in the document at each point to come back and
add the appropriate link back to the document once the rest of the
existing material is somewhere visible.

Fixes #18.

This is basically a snapshot of an in-progress document, moved to markdown and prepared for sharing with the wider community. It isn't finished. It isn't even necessarily up to date with the latest thinking on any particular area. But I think it will make more sense to land it as essentially a collective WIP and let people iterate on any given section as those details get sorted out. Even in its current form, I think it still provides a starting point and gives people the feel of what this will look like. There are a number of document links lost in this conversion. I've carefully left a `TODO` in the document at each point to come back and add the appropriate link back to the document once the rest of the existing material is somewhere visible. These were all fairly easy to preserve as they primarily were links out to an entire document.

chandlerc · 2020-05-27T09:04:52Z

I think this is in a state where folks can start reading it and discussing. A couple of points on discussion here though...

The big one: on any specific topic, please try to keep discussion fairly light and high-level. I'll try to add some rough notes about major high-level concerns, but it is easy to become swamped in those. This is not intended to propose any particular set of details as the path forward, only to collect a high level picture (even if stale & inaccurate from time to time). The right place to dig into details, or really push on any specific direction is through a detailed proposal in that area.

I am especially interested if there are major improvements people would like to see in the overall organization. So far, I've not loved any of the organization, but this one seems at least "OK" for now. But if there are concrete suggestions for ways to structure that would be better, I'd love to hear ideas and discuss them.

Also interested in better ways to phrase and word the top-level introduction to best convey the nature and purpose of the document -- serving as an overview and index across the design space, not pushing any one area forward with "this is how it should be".

docs/designs/language-design-overview.md

josh11b

I don't want to get into an extended debate here, but I thought making an attempt to make the document a bit more accurate would be beneficial. I think it would be reasonable to just delete sections that we know are inaccurate until later if you want to get this in quickly.

josh11b · 2020-06-01T23:13:01Z

docs/designs/language-design-overview.md

+> **Note**: this implies that other names within your own package but not
+> declared within the file must be found via the package name. It isn't clear if
+> this is the desirable end state. We need to consider alternatives where names
+> from the same module or any module in the same package are made immediately


When you say "module" here do you mean the "library" you defined above?

Yes, good catch.

josh11b · 2020-06-01T23:28:11Z

docs/designs/language-design-overview.md

+Carbon also disallows the use of shadowed unqualified names, but not the
+_declaration_ of shadowing names in different named scopes. Because all


I did not follow this -- perhaps an example would make it clearer?

josh11b · 2020-06-01T23:35:11Z

docs/designs/language-design-overview.md

+that adding names to the standard library or importing a new package (both of
+which bring new names into the current package's scope) doesn't force renaming


This bit about adding names to a package that is imported adds names to the package's scope doesn't sound consistent with what you said before, nor consistent with how I expect/want things to work.

Tried to make this more clear in the example, but let me know if it still isn't clear.

That said, I'm not really trying to endorse this. I'm happy removing a bunch of this if you want -- I mostly think it is interesting to consider the underlying ideas of restricting shadowing by limiting unqualified name lookup and falling back to qualified name lookup.

josh11b · 2020-06-01T23:45:08Z

docs/designs/language-design-overview.md

+  - Bitwise: `2 & 3`, `2 | 4`, `3 ^ 1`, `1 <&lt; 3`, `8 >> 1`, `~7`
+  - Relational: `2 == 2`, `3 != 4`, `5 &lt; 6`, `7 > 6`, `8 &lt;= 8`, `8 >= 8`


Suggested change

- Bitwise: `2 & 3`, `2 | 4`, `3 ^ 1`, `1 << 3`, `8 >> 1`, `~7`

- Relational: `2 == 2`, `3 != 4`, `5 < 6`, `7 > 6`, `8 <= 8`, `8 >= 8`

- Bitwise: `2 & 3`, `2 | 4`, `3 ^ 1`, `1 << 3`, `8 >> 1`, `~7`

- Relational: `2 == 2`, `3 != 4`, `5 < 6`, `7 > 6`, `8 <= 8`, `8 >= 8`

I've noticed this is an issue with our docs-to-markdown exporter.

docs/designs/language-design-overview.md

josh11b · 2020-06-02T03:28:16Z

docs/designs/language-design-overview.md

+should cast or convert the argument to control the deduction. The explicit type
+is passed after a runtime parameter. While this makes that type unavailable to
+the declaration of the runtime parameter, it still is a true type and available
+to use as a type even within the remaining parts of the template function
+declaration.


I suspect these last sentences are talking about something that is no longer relevant.

I just think I was using really bad words. Anyways, rewritten to be I think somewhat more clear.

josh11b · 2020-06-02T03:28:46Z

docs/designs/language-design-overview.md

+> **Note**: there is an important open question about how to distinguish between
+> a non-type parameter of a template function which is a normal runtime
+> parameter and one which must trigger instantiation and become available in the
+> function as a compile time constant. Currently, the most appealing technique
+> is an annotation of the parameter itself, but we still don't have a very
+> appealing suggestion for how to spell this annotation without making the
+> declaration excessively verbose. An alternative would be to give up on the
+> single-parameter sequence and require the template parameters to be separate
+> so the above becomes `template fn Convert[Type: T](Type: U)(T: source) -> U`
+> and the call becomes `Convert(Float)(i)`.


Also out of date.

josh11b · 2020-06-02T03:30:24Z

docs/designs/language-design-overview.md

+> **TODO:** Update all of this to match the generics proposal when we have a
+> draft published, and link to it.


I would be much more comfortable omitting these sections until they can be rewritten than including them as-is.

We discussed this offline a bit... I agree that the sections don't currently make much sense, just representing very dated and not coherent idle speculation... However, I also feel like there is some minimal value here to help people begin thinking outside of the C++ constrnucts of templates and inheritance, and to provide some common syntax primitives around interfaces that can be useful in examples and other discussions.

I'm currently rewritting the entire section to both be much more minimal while still giving some flavor of the directions we're exploring here. I'll update again when I have new text here for a fresh look and then let's see if we can arrive at something that still provides this "flavor" level value without ending up misleading.

josh11b · 2020-06-02T03:34:52Z

docs/designs/language-design-overview.md

+be the only non-whitespace on the line. Carbon also supports a nestable block
+comment syntax:
+
+```
+/*
+...
+  /*
+  ...
+  */
+...
+*/
+```
+
+While these use the block comment syntax of C and C++, they allow nesting much
+like with Swift. The opening (`/*`) and closing (`*/`) are required to be the
+first and last (respectively) thing on the line. Both of these comment styles


I'd just delete this bit about /* ... */ for now. Including it and then having notes about them maybe not actually being included is too much detail for an overview document like this, which has a lot to cover, and any place we can shorten will be beneficial.

Sure, tried to shorten up a bit.

josh11b · 2020-06-02T03:36:16Z

docs/designs/language-design-overview.md

+a local variable named `p` which is then returned.
+
+### Pattern matching as function overload resolution
+


Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com> Co-authored-by: josh11b <josh11b@users.noreply.github.com>

chandlerc

First off, thanks for the thorough review. =D

I think I got through all of the comments left and responded. I'll make a second pass to double check and mark all the ones that seem definitive as "resolved" tomorrow.

Appreciate not going too far down the debate path here. I think there are really two areas with substantial issues:

Tuples (especially w.r.t. function calls)
Generics (and templates, etc)

For 2, I've got a pretty clear idea of what might both be a more useful and much more up-to-date and accurate summary for generics. I've deleted most of the egregious text and left some TODOs, I plan to fill that in before landing though, I just didn't want to wait on finishing that text to send out the rest of my updates. The template sections I was able to pretty quickly update to something plausible (or at least, they may be plausible once I address my TODOs to give the introduction section that ties them together).

For 1, I've responded inline and tried to re-focus the text in the document on the more useful (and I think less interesting / difficult / uncertain (to me) aspects. It still isn't perfect, and I've tried to make sure there are at least very explicit notes about the uncertainty here. Unsure if this is really enough in the way of disclaimer to avoid confusion, but at least for me it seems pretty close. Happy to iterate here until we find something that strikes a reasonable balance though.

docs/designs/language-design-overview.md

chandlerc · 2020-06-10T07:18:13Z

docs/designs/language-design-overview.md

+be the only non-whitespace on the line. Carbon also supports a nestable block
+comment syntax:
+
+```
+/*
+...
+  /*
+  ...
+  */
+...
+*/
+```
+
+While these use the block comment syntax of C and C++, they allow nesting much
+like with Swift. The opening (`/*`) and closing (`*/`) are required to be the
+first and last (respectively) thing on the line. Both of these comment styles


Sure, tried to shorten up a bit.

chandlerc · 2020-06-10T07:49:47Z

docs/designs/language-design-overview.md

+We'll get into more detail about what these mean and how they all work as we go
+along.
+
+### Basic names and scopes


Good call, added a section and restructured a bit so it fits.

chandlerc · 2020-06-10T07:53:06Z

docs/designs/language-design-overview.md

+> **Note**: this implies that other names within your own package but not
+> declared within the file must be found via the package name. It isn't clear if
+> this is the desirable end state. We need to consider alternatives where names
+> from the same module or any module in the same package are made immediately


Yes, good catch.

chandlerc · 2020-06-10T10:04:53Z

docs/designs/language-design-overview.md

+and run-time parameters.
+
+```
+template fn Convert[Type: T](T: source, Type: U) -> U {


Done and entire section rewritten. Similar to above, this references as-yet-unwritten high level ideas that are common such as implicit parameters. Will add that as I get the generics bit fleshed out and then need to make sure this lines up coherently. But it is at least much less actively wrong/misleading.

chandlerc · 2020-06-10T10:15:32Z

docs/designs/language-design-overview.md

+should cast or convert the argument to control the deduction. The explicit type
+is passed after a runtime parameter. While this makes that type unavailable to
+the declaration of the runtime parameter, it still is a true type and available
+to use as a type even within the remaining parts of the template function
+declaration.


I just think I was using really bad words. Anyways, rewritten to be I think somewhat more clear.

chandlerc · 2020-06-10T10:15:41Z

docs/designs/language-design-overview.md

+> **Note**: there is an important open question about how to distinguish between
+> a non-type parameter of a template function which is a normal runtime
+> parameter and one which must trigger instantiation and become available in the
+> function as a compile time constant. Currently, the most appealing technique
+> is an annotation of the parameter itself, but we still don't have a very
+> appealing suggestion for how to spell this annotation without making the
+> declaration excessively verbose. An alternative would be to give up on the
+> single-parameter sequence and require the template parameters to be separate
+> so the above becomes `template fn Convert[Type: T](Type: U)(T: source) -> U`
+> and the call becomes `Convert(Float)(i)`.


chandlerc · 2020-06-10T10:16:06Z

docs/designs/language-design-overview.md

+#### Specialization
+
+An important feature of templates in C++ is the ability to customize how they
+end up specialized for specific types. Carbon also supports this for templates:


yes, lemme just say that too....

chandlerc · 2020-06-10T10:19:24Z

docs/designs/language-design-overview.md

+#### Specialization
+
+An important feature of templates in C++ is the ability to customize how they
+end up specialized for specific types. Carbon also supports this for templates:


Also tried to clarify that by leveraging pattern matching there is potentially more going on here. The only hting I want to really be concrete about though is that this gives us a potential integrated way to get extremely comparable facilities to what C++ provides so we know we're covering that space.

jonmeow · 2020-06-10T18:11:28Z

docs/designs/language-design-overview.md

+import Shadow library OtherLib;
+
+// We can reference the imported library:
+alias ??? OtherLibType = Shadow.SomeType;


Suggested change

alias ??? OtherLibType = Shadow.SomeType;

alias ??? OtherLibType = OtherLib.Shadow.SomeType;

I'm a bit confused here, isn't "Shadow" here unqualified, and thus an error? Shouldn't this require OtherLib.Shadow.SomeType?

I think this whole example (and possibly idea?) is just broken, and so I'm deleting all of it. We shouldn't figure out how this does work here, that should be in the naming proposal. I'll think more about what we really want around shadowing and try again in that doc! =D

jonmeow · 2020-06-10T18:15:02Z

docs/designs/language-design-overview.md

-with parentheses to have clear and distinct syntax and match both the common
-case (multiple parameters) and common convention in programming languages around
-function notation. `Int*` `Int*?` `Int[]`
+Generally, functions pattern match a single tuple value of the arguments (with


Broad comment -- I was digging and the dev style guide strongly discourages use of parentheticals, you might want to go through removing uses.
https://developers.google.com/style/parentheses

This is a good point, I'm going through and trying to clean up my use of them. It's a long standing habit, so apologies when I inevitable regress, but definitely keep calling it out.

I think there are some uses that (as the guide says) are OK when judiciously used... but long parentheticals like this seem clearly better written differently. =]

chandlerc

Replying to the new comments from Jon as I work on these and some other updates.

chandlerc · 2020-06-12T03:07:31Z

docs/designs/language-design-overview.md

+import Shadow library OtherLib;
+
+// We can reference the imported library:
+alias ??? OtherLibType = Shadow.SomeType;


I think this whole example (and possibly idea?) is just broken, and so I'm deleting all of it. We shouldn't figure out how this does work here, that should be in the naming proposal. I'll think more about what we really want around shadowing and try again in that doc! =D

chandlerc · 2020-06-12T03:09:39Z

docs/designs/language-design-overview.md

-with parentheses to have clear and distinct syntax and match both the common
-case (multiple parameters) and common convention in programming languages around
-function notation. `Int*` `Int*?` `Int[]`
+Generally, functions pattern match a single tuple value of the arguments (with


This is a good point, I'm going through and trying to clean up my use of them. It's a long standing habit, so apologies when I inevitable regress, but definitely keep calling it out.

I think there are some uses that (as the guide says) are OK when judiciously used... but long parentheticals like this seem clearly better written differently. =]

zygoloid · 2020-06-12T22:57:00Z

docs/designs/language-design-overview.md

+
+Our current proposed naming convention, which we at least are attempting to
+follow within Carbon documentation in order to keep code samples as consistent
+as possible:


Suggested change

as possible:

as possible, is:

zygoloid · 2020-06-12T22:58:05Z

docs/designs/language-design-overview.md

+
+- `UpperCamelCase` for names of compile-time resolved constants, such that they
+  can participate in the type system and type checking of the program.
+- `lower_snake_case` for names of run-time resolved values.


Is it worth mentioning here that we intend to use lower_snake_case for keywords too?

Yeah, and highlight (ba-dum) that syntax highlighting helps those stand out on their own, and why. I'll make a suggestion on Jon's new structure.

Actually, this seems better handled in the lexical conventions. This section is about the naming conventions within identifiers, and I feel like bringing up keywords is likely to just be confusing.

docs/designs/language-design-overview.md

zygoloid · 2020-06-12T23:04:03Z

docs/designs/language-design-overview.md

+> **Note**: this implies that other names within your own package but not
+> declared within the file must be found via the package name. It isn't clear if
+> this is the desirable end state. We need to consider alternatives where names
+> from the same library or any library in the same package are made immediately
+> visible within the package scope for unqualified name lookup.


When deciding what to do here, we should think about whether we want to support compilation at a finer granularity than package-at-a-time. We have evidence that the Rust crate-at-a-time compilation model results in compilation performance problems.

Agreed. Not sure there is anything we can say this early though?

zygoloid · 2020-06-12T23:07:13Z

docs/designs/language-design-overview.md

+Because all unqualified name lookup is locally controlled, shadowing isn't
+needed for robustness and is a long and painful source of bugs over time.
+Disallowing it provides simple, predictable rules for name lookup. However, it
+is important that adding names to the standard library or importing a new
+package (both of which bring new names into the current package's scope) doesn't
+force renaming interfaces that may have many users. To accomplish this, we allow
+code to declare shadowing names, but references to that name must be qualified.
+For package-scope names, this can be done with an explicit use of the current
+package name: `PackageName.ShadowingName`.


Is adding a new name to the prelude a breaking change? (Would you need to update all existing code to stop using that name as an unqualified identifier first, before upgrading?) Perhaps we could give names from the prelude the same treatment that #17 suggests for keywords: if you declare them anywhere in a file, you don't get to use them with their built-in meaning in that file.

I'm OK with adding a new name being a breaking change exactly as much as I'm OK with adding keywords being a breaking change. =] And I'm also happy finding similar mechanisms to allow people to handle the fallout in sustainable ways, as long as neither one stops progress of adding keywords when justified. =D Anyways, probably best to handle it in #17 rather than here.

zygoloid · 2020-06-12T23:11:31Z

docs/designs/language-design-overview.md

+```
+std::int64_t Sum(std::int64_t a, std::int64_t b);
+
+// Or with the new trailing return type syntax:


Suggested change

// Or with the new trailing return type syntax:

// Or with trailing return type syntax:

(It's not all that new any more.)

zygoloid · 2020-06-12T23:26:41Z

docs/designs/language-design-overview.md

+package MyProgram library Entry;
+
+fn Run() -> Bool {
+  Print("Hello World!");


This isn't the right place for this comment, but: I view Carbon as being a language for writing code at scale, where you probably don't want to use Print and would instead want some domain-specific output mechanism; therefore, I don't think it should be visible by default in Carbon source files -- I think people should be required to think at least a little bit before using it. That said, I think

We should be able to support the kinds of small utilities where Print is useful. Putting a bunch of such functionality into some standard library "tool utilities" package seems like a good idea.

Being able to print out a debugging string is certainly useful, and it might be reasonable to make functionality for that be available by default.

zygoloid · 2020-06-12T23:28:56Z

docs/designs/language-design-overview.md

+> **TODO:** Need a comprehensive design document to underpin these, and then
+> link to it here.
+
+These types are fundamental to the language as they aren't comprised of other


Suggested change

These types are fundamental to the language as they aren't comprised of other

These types are fundamental to the language as they aren't formed from other

(https://grammarist.com/usage/compose-comprise/)

zygoloid · 2020-06-12T23:31:30Z

docs/designs/language-design-overview.md

+> should be defined in Carbon code rather than special. Clearly they can't be
+> directly implemented w/o help, but it might still be useful to force the
+> programmer-observed interface to reside in code. However, this can cause


I'm not certain that we can't implement many of these types directly without help. For example, I could imagine allowing a direct implementation of Type for a given value, that allows Carbon code to specify layout properties of a type. There are circularity problems to deal with (eg, what is the return type of Type.Size?) but perhaps we could cut that cycle somewhere that's invisible to Carbon programs.

mconst · 2020-06-17T04:41:48Z

docs/designs/language-design-overview.md

+that is not available as part of the type system would be named `n`, even if it
+happened to be immutable or only take on a single value. Functions and most
+types will be in `UpperCamelCase`, but a type where only run-time type
+information queries are available would end up as `lower_snake_case`.


How does this apply to generic arguments to a function, which are compile-time constants at the call site but not within the function body? This explanation makes it sound like they should be lowercase, since you can't use them in compile-time-only contexts, but most of the examples I've seen use uppercase.

I don't really follow, I think the generic examples are using the types as compile-time constants...

fn GenericF[SomeInterface:$ GenericT](GenericT: value) -> Void

Here, GenericT is used in a compile time context -- it is part of the parameter declaration?

mconst · 2020-06-17T06:38:43Z

docs/designs/language-design-overview.md

+> explicit types or other questions in this space). That was a very limited PhD
+> student's study of Java programmers that seemed to indicate improved latency
+> for recalling the type of a given variable name with types on the left (as in
+> C++). However, those results are _far_ from conclusive.


If you're looking for data points on how people respond to this syntax: this tripped me up in your presentation when I tried to read example Carbon code for the first time, and it continues to trip me up over a month later. Literally every other language I know of that uses this syntax does it in the other order.

Yep, this is a point that I think folks are very much thinking about. Happy to talk more in depth about this at some point if you want, but probably this doc isn't the best place.

chandlerc · 2020-06-19T23:53:57Z

@jonmeow has what I think is a really nice (but different) structured approach in #83 that I much prefer, and so I'm closing this PR out in favor of his for now.

I've tried to respond to some of the questions here. I think most of the immediate adjustments suggested have been reflected in #83, but if anyone sees one that got missed, I'll try to keep following this thread just-in-case.

#83) Co-authored by: chandlerc - Based on [PR 22](#83) - [Idea topic](https://forums.carbon-lang.dev/t/proposal-for-an-incomplete-rough-high-level-overview-ready-for-early-feedback/52) - [RFC](https://forums.carbon-lang.dev/t/rfc-an-incomplete-early-and-in-progress-overview-of-the-language-design/73) - [Decision announcement](https://forums.carbon-lang.dev/t/accepted-an-incomplete-early-and-in-progress-overview-of-the-language-design/110) This proposal should be considered a starting point of the language design. It's not intended to be final; language details may change. This is intended to offer a reasonable starting point for: - Example code. - Conceptualizing Carbon at a high level. - Reasonable, but not necessarily final, approaches to features in README.md. - If any idea is obviously bad, we can clean it up here. This proposal is not intended to achieve: - A whole language design. - This is way too much work for a single proposal; this is a skeletal framework only. - As we work on feature-specific designs, we may decide to use other approaches. That's fine: we only need somewhere to start. - The summaries in README.md may be expected to change over time. - Feature-specific files aren't intended to be well-written or comprehensive. They are a quick jot of prior thoughts. - We want to avoid getting stuck on language details that we should consider more carefully regardless. If you're passionate about a feature, please feel free to start a new proposal for it. - Each and every aspect of the suggested overview should be subject to careful examination and justification before it becomes a settled plan of record. Chandler started this with #22. I've taken it over with the following changes: - More of a directory hierarchy. - Trying to thin out the main file (now README.md) to lighter summaries of features. - Details/rationale/alternatives should be in feature-specific files. - Draft files are linked as references where added. For an example of how we may proceed with feature-specific designs, see #80. In this structure: - docs/design/README.md mentions interoperability, with a light overview. - The light overview is not yet in #80. - docs/design/interoperability/README.md goes into more depth on interoperability, covering key points of the approach. - Individual files in docs/design/interoperability/* go into more depth on interoperability. Simple designs may not have a subdirectory. All current feature-specific designs do not -- they may be moved later.

jonmeow reviewed May 27, 2020

View reviewed changes

docs/designs/language-design-overview.md Show resolved Hide resolved

jonmeow reviewed May 27, 2020

View reviewed changes

docs/designs/language-design-overview.md Outdated Show resolved Hide resolved

jonmeow reviewed May 27, 2020

View reviewed changes

docs/designs/language-design-overview.md Show resolved Hide resolved

josh11b reviewed Jun 2, 2020

View reviewed changes

jonmeow added proposal A proposal WIP labels Jun 3, 2020

chandlerc and others added 4 commits June 9, 2020 23:52

Merge branch 'master' into lang-design-overview

fbbc0a8

Extensive updates based on review feedback.

f2d0fcf

Apply suggestions from code review

6be32d3

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com> Co-authored-by: josh11b <josh11b@users.noreply.github.com>

More tweaks

3c13624

chandlerc commented Jun 10, 2020

View reviewed changes

jonmeow reviewed Jun 10, 2020

View reviewed changes

chandlerc commented Jun 12, 2020

View reviewed changes

zygoloid reviewed Jun 13, 2020

View reviewed changes

mconst reviewed Jun 17, 2020

View reviewed changes

jonmeow mentioned this pull request Jun 17, 2020

An incomplete, early, and in-progress overview of the language design. #83

Merged

chandlerc closed this Jun 19, 2020

pk19604014 mentioned this pull request Apr 6, 2022

clang crash when running bazel test --config=fuzzer #1173

Closed

pk19604014 mentioned this pull request May 25, 2022

explorer crashes on a self-referencing alias #1294

Closed

pk19604014 mentioned this pull request May 31, 2022

explorer crashes on var auto = i32; construct #1301

Closed

tkadur mentioned this pull request Jul 21, 2022

explorer has lifetime(?) bug with String associated constants #1439

Closed

Penfore mentioned this pull request Oct 22, 2022

[CLOSED] Issue when printing a variable auto typed #2335

Closed

FelipeLopes mentioned this pull request Nov 2, 2022

LLVM stacktrace when running generic code with interfaces #2367

Closed

enstazao mentioned this pull request Dec 23, 2023

FATAL failure at explorer/syntax/prelude.cpp:22 #3539

Closed

TabletBoii mentioned this pull request Dec 26, 2023

Bazel explorer installation error #3540

Closed

		Carbon also disallows the use of shadowed unqualified names, but not the
		_declaration_ of shadowing names in different named scopes. Because all

		that adding names to the standard library or importing a new package (both of
		which bring new names into the current package's scope) doesn't force renaming

		- Bitwise: `2 & 3`, `2 \| 4`, `3 ^ 1`, `1 << 3`, `8 >> 1`, `~7`
		- Relational: `2 == 2`, `3 != 4`, `5 < 6`, `7 > 6`, `8 <= 8`, `8 >= 8`

		> TODO: Update all of this to match the generics proposal when we have a
		> draft published, and link to it.

		a local variable named `p` which is then returned.

		### Pattern matching as function overload resolution

	alias ??? OtherLibType = Shadow.SomeType;
	alias ??? OtherLibType = OtherLib.Shadow.SomeType;

	// Or with the new trailing return type syntax:
	// Or with trailing return type syntax:

	These types are fundamental to the language as they aren't comprised of other
	These types are fundamental to the language as they aren't formed from other

An incomplete, early, and in-progress overview of the language design. #22

An incomplete, early, and in-progress overview of the language design. #22

Conversation

chandlerc commented May 21, 2020

chandlerc commented May 27, 2020

josh11b left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chandlerc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chandlerc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mconst Jun 17, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chandlerc commented Jun 19, 2020

mconst Jun 17, 2020 •

edited

Loading