Coder Social home page Coder Social logo

Comments (4)

mikmoore avatar mikmoore commented on June 16, 2024

This is a clever way to implement unreachable, but I don't like it. It's too hard to use properly. An unreachable() function or macro seems to be a much safer and more ergonomic implementation.

Base.@assume_effects is annotated at the function level. This makes it too coarse-grained to use responsibly for this purpose. EDIT: it can be applied to blocks in upcoming versions (thanks for the correction below). A :nothrow annotation like this would also seem to risk applying recursively to any functions called (or at least to inlined functions), which makes this dangerous in the first place and a maintenance nightmare if any of those called functions ever change.

I think we shouldn't have this for many of the same reasons we don't have global @fastmath (any more).

from julia.

nsajko avatar nsajko commented on June 16, 2024

Not true, since v1.11 @assume_effects may be appllied to a code block: https://docs.julialang.org/en/v1.12-dev/base/base/#Base.@assume_effects. For example the nothrow below should only apply to the 7::Union{} AFAIK:

Base.@assume_effects :nothrow let
    7::Union{}
end

Obviously unreachable() is intrinsically unsafe, however, given that we can apply nothrow to a code block, I think my proposal is as safe as possible?

from julia.

mikmoore avatar mikmoore commented on June 16, 2024

Not true, since v1.11

Thanks for the correction. I vaguely recalled seeing something like that but it's hard to keep up with all the upcoming changes.

Really, you're right that (in at least some senses) @assume_effects should have this power. Otherwise it's not really assuming the stated effects. Although taking that line of thinking further, we should allow any provable violation of an effects flag to emit an unreachable.

That said, as far as I understand (though my understanding is poor), @assume_effects has virtually no impact on the internal operation of the function it's defined on. Its impact is actually on call sites of that function. Given that understanding, this proposal would dramatically expand the scope of @assume_effects's operation. So it seems like the wrong place for this functionality.

I also don't relish the idea of encouraging people to impose blatantly false effects to twist the compiler into emitting unreachable. There should be a more direct option (although it could co-exist with the proposed feature).

from julia.

nsajko avatar nsajko commented on June 16, 2024

xref #54436

from julia.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.