-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Unrestricted block arguments are Nop in macros #5334
Comments
I also facing same problem when fetching an information of block is need? or not. class Foo
def foo1
yield
end
def foo2(&block)
block.call
end
{% for m in @type.methods %}
{% p [m.name, :block, !! m.block_arg] %}
{% end %}
end
How can I know the fact that foo1 needs block in macros? |
In the implementation we have a property for that, it's called |
A use case would be to generate only one method in the macro Lines 1083 to 1095 in 84fa9ec
|
According to the normalizer a bare class Foo
macro finished
{% for method in @type.methods %}
{% puts method.block_arg.is_a? Nop %} # => true
{% end %}
end
def yield_and_block_with_type(&block : ->)
yield
end
end |
The
.block_arg
macro method on method declarations only returns anArg
if the block has a type restriction. If there is no restriction thenNop
is returned.For example, this should print true, true, false, false. Currently it prints true, true, true, false.
By removing the
if
statement in theDef
normalizer this works as expected - the last two methods have ablock_arg
.However, instead of fixing this, I think a better move would be to make an
accepts_block?
macro method that checks whether the method has ayield
or a&block
arg. Unless there is a need for getting the name of the block arg?This is on master (and is the same in
0.23.1
, fwiw) on Ubuntu 16.04The text was updated successfully, but these errors were encountered: