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

Local variable is shadowed by a template parameter of an ancestor #146

Open
AkiSakurai opened this issue Dec 29, 2024 · 6 comments · May be fixed by #147
Open

Local variable is shadowed by a template parameter of an ancestor #146

AkiSakurai opened this issue Dec 29, 2024 · 6 comments · May be fixed by #147

Comments

@AkiSakurai
Copy link
Contributor

import std.io;

struct inner 
{
  u32 size = 42;
  std::print("size:{}\nthis.size:{}", size, this.size); 
};

struct outer<auto size> 
{
    inner inner;
};

outer<24> outer;
// I: size:24
// I: this.size:42
@paxcut
Copy link
Contributor

paxcut commented Dec 29, 2024

Maybe I am missing some important difference between this and the issue previous to this one ( #144 )?

@AkiSakurai
Copy link
Contributor Author

The previous one had the nested template arguments overridden by a local variable due to call by name.

This one, a variable inside a non-template struct gets overridden by a template parameter of the parent templated struct, where it should be scoped and not accessible without using .parent.

@paxcut
Copy link
Contributor

paxcut commented Dec 29, 2024

Aren't both of them caused by the pattern language delaying assignment until needed in an evaluation? The value chosen is always the one in scope at the time of evaluation, not at the time of definition.

@paxcut
Copy link
Contributor

paxcut commented Dec 30, 2024

Using name shadowing as part of the description of the bug is confusing and makes it harder to understand the actual bug being reported. It is not a matter of priorities in variable selection. The template argument is just not accessible to the inner pattern regardless of its name. The example code should emphasize the nature of the bug.

A clearer example would have been:

import std.io;
struct Inner {
    std::print("{}",size);
};

struct Outer<auto size> {
    Inner inner;
};

Outer<10> outer@0;

which doesn't give errors and prints 10.
The title of the issue also contributes to the confusion because it should not mention name shadowing. It should have been something like "Template argument in parent can be accessed from child directly without using parent keyword".

Do the changes in your PR fix the real bug? the result of the code I posted should be an error but if you only made it so that the local variable is chosen first then the bug was not really fixed.

@AkiSakurai
Copy link
Contributor Author

AkiSakurai commented Dec 31, 2024

which doesn't give errors and prints 10. The title of the issue also contributes to the confusion because it should not mention name shadowing. It should have been something like "Template argument in parent can be accessed from child

The problem persists without the child struct. There are indeed two problems here.

import std.io;


struct template<auto size> 
{
    u32 size = 16;
    std::print("size: {}\nthis.size:{}\n", size, this.size);;
};

template<24> outer;
// I: size:24
// I: this.size:42

@paxcut
Copy link
Contributor

paxcut commented Dec 31, 2024

But the problem is not that the order of evaluation is one way or the other. The problem is that variable names should not be allowed to repeat within the same scope. you are defining two variables with the same name in the same scope. The result should be the same as shown in the picture below.
image

You can argue that the two are separate scopes, that the template argument lives in the bigger scope and the variable lives in the smaller scope. In that case you need to have some way to be able to obtain the values for both variables and shadowing either one would not be correct because that implies that only one variable with that name can exist which is a contradiction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants