Documentation & Design Notes Review
DyXel opened this issue · comments
I was thinking about opening a separate issue, but they are all pretty minor and think should fit fine in just this one.
- General: It seems code blocks line counts and actual code are ever-so-slightly misaligned, which amplifies over examples and looks bad...
- Design note: Defaults are one way to say the same thing:
- Says initializer its supported but compiler errors out in most cases (explicitly disabled, maybe misleading?).
- Should probably mention that without braces (
{ }
) thereturn
is also implicit.
- Docs: From functions to local scopes, and back again
- Same as above's design note.
- Design note: Postfix operators: * and &
f: (i:int) -> * (:int) -> string = {/*...*/}
doesn't actually compile. It reports a problem with the function pointer syntax.
- Docs: Common programming concepts
- Has
(note: allowed in unsafe code only)
, what does this mean? I think it needs to be expanded, and maybe given a concrete example.
- Has
- Docs: Common expressions
- Function calls example doesn't compile:
clog
should bestd::clog
(didn't even know this was a thing), UFCSfprintf
as cool as it looks would never compile, since string interpolation would return something that isn'tconst char*
.
- Function calls example doesn't compile:
- Design note: Capture
- Postconditions are still using the old syntax.
- String interpolation in Python should actually be
f"My name is {name}"
(f-strings).
- Docs: Guaranteed initialization
- The array example is missing the
<<
for thestd::cout
s, theload_from_disk
function doesn't initialize buffer butx
.
- The array example is missing the