Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[SUGGESTION] Independent order and type data members #406

Closed
realgdman opened this issue May 1, 2023 · 4 comments
Closed

[SUGGESTION] Independent order and type data members #406

realgdman opened this issue May 1, 2023 · 4 comments

Comments

@realgdman
Copy link

realgdman commented May 1, 2023

Independent order of declaration works for functions, because definitions of those functions put after declarations of variables.
However, declarations of types can intertwine with variables, so data members not always can refer those globals.

Code Example
S: type = {
mi: int = i; //cpp1 error - undeclared i
pi: * int = i&; //cpp1 error - undeclared i

f: () = std::cout << i; //ok, function definition pushed down
}

main: () = {
li:= i; //ok, function definition pushed down
std::cout << i; //ok
}

i: int = 42;

Additional note
Probably hard to solve, requiring some sort of dependency graph
Namespaces doesn't seem to help here, because namespace itself still may be placed after class declaration.
In this case workaround is simple - move i: int = 42; declaration before S declaration

@JohelEGP
Copy link
Contributor

There's also no order independence in a type's Cpp1 declaration (template parameters and requires clause).
This fails because origin has not been declared (https://cpp2.godbolt.org/z/9WeKsef3j):

unit: @struct type       = { }
quantity_point: @struct <O: * origin, U: * unit, N> type = { }
origin: @struct type = { }
main: () = { }
main.cpp2:2:10: error: unknown type name 'origin'
    2 | template<origin* O, unit* U, typename N> class quantity_point;
      |          ^

@JohelEGP
Copy link
Contributor

Here is the order of emitted Cpp1
(template implied where possible):

  • Phase 1 "Cpp2 type declarations"
    first emits #include "cpp2util.h".
  • Phase 1 "Cpp2 type declarations"
    then emits, in source order:
    • Of a Cpp2 type, its Cpp1 type declaration.
  • Phase 2 "Cpp2 type definitions and function declarations"
    then emits, in source order:
    • Of a Cpp2 type, its Cpp1 type definition and member function declarations.
    • Of a Cpp2 function, its Cpp1 declaration.
    • Of a Cpp2 non-expression alias, its Cpp1 declaration.
    • Of a Cpp2 expression alias, its Cpp1 definition.
    • An import declaration is emitted as-is.
    • Cpp1 code is emitted as-is.
      That includes #include directives, even if for a Cpp2 source file (see [BUG] Can't use #included declaration in requires clause #470).
  • Phase 3 "Cpp2 function definitions"
    then emits, in source order:
    • Of a Cpp2 type, its member function definitions.
    • Of a Cpp2 function, its Cpp1 definition.

That results in these order dependencies:

  • The body of a function is order independent.
    I think Cpp2 guarantees this.
  • Anything else can be source code order dependent according to how things are emitted above.
    Notably, a function with a deduced return type can't be used before it's defined.
    E.g., if A and B are Cpp2 types,
    you can use the incomplete type A in type B's template parameter list or requires clause
    if A comes before B in source code.

@JohelEGP
Copy link
Contributor

Probably hard to solve, requiring some sort of dependency graph

See the last paragraph of #75 (comment).

@JohelEGP
Copy link
Contributor

@hsutter What do you think about concepts and order independence?

Right now, a concept is emitted during Phase 2 "Cpp2 type definitions and function declarations".
But that's no good if you want to use it to constrain template types in the same TU.

Repository owner locked and limited conversation to collaborators Aug 30, 2023
@hsutter hsutter converted this issue into discussion #641 Aug 30, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants