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

[Feature Request] Parametrize Self on struct parameters #2628

Closed
1 task done
rd4com opened this issue May 11, 2024 · 3 comments
Closed
1 task done

[Feature Request] Parametrize Self on struct parameters #2628

rd4com opened this issue May 11, 2024 · 3 comments
Labels
enhancement New feature or request mojo-repo Tag all issues with this label

Comments

@rd4com
Copy link
Contributor

rd4com commented May 11, 2024

Review Mojo's priorities

What is your request?

Hello,

here is a feature request that seem useful:

@value
struct MyStruct[mutable: Bool]:
    var x: Int
    #fn set(inout self: Self[True],arg: Int): #'MyStruct' expects 0 parameters, but 1 was specified
    #    self.x=arg

fn set(inout arg:MyStruct[True],val:Int): #👍
    arg.x = val

fn main():
    var x = MyStruct[True](1)
    set(x,1)
    #x.set(2)
    

It could also be useful with decayed reference but not sure !

struct Reference[..., is_decay:Bool=True]:
    fn __getitem__(self: Self[_,_,_,_,False])->Reference[
        self.type, 
        self.is_mutable ,
        self.lifetime ,
        self.address_space, 
        True
    ]:
        return __get_ref_as_decay(self)

What is your motivation for this change?

The motivation is to make struct more parametrizable in general,

the idea occurred to be me while trying to contribute a feedback on the Decayed lifetime proposal.

This could allow to convert a non-decaying one into a decaying one, in order to __getitem()__ only the non decaying references.

That way, only non-decaying references could be manually dereferenced, and decaying ones would be auto-dereferenced.

Not sure if it would work, but if it could be useful for that, it could be useful for many usecases.

Any other details?

No response

@rd4com rd4com added enhancement New feature or request mojo-repo Tag all issues with this label labels May 11, 2024
@nmsmith
Copy link
Contributor

nmsmith commented May 11, 2024

I've thought about this in the past, but I don't think it's a good idea. The whole point of Self is to act as a shorthand for writing out the full type with all of its parameters. Beyond that, it has no purpose. If you're going to write out the parameters, you may as well use the full struct name.

Also, Self needs to have a singular, consistent meaning, so it doesn't seem reasonable to make parameters on Self "optional", in the sense that if you omit them, they are populated with the parameter values of the enclosing definition. (As they are today.)

@soraros
Copy link
Contributor

soraros commented May 11, 2024

And the use case is covered by conditional conformance I think.

@rd4com
Copy link
Contributor Author

rd4com commented May 29, 2024

👍 It makes sense, thanks for taking the time to explain !

@rd4com rd4com closed this as completed May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request mojo-repo Tag all issues with this label
Projects
None yet
Development

No branches or pull requests

3 participants