December 09, 2022 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eyal@weka.io --- Comment #19 from RazvanN <razvan.nitu1305@gmail.com> --- *** Issue 21862 has been marked as a duplicate of this issue. *** -- |
December 09, 2022 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 --- Comment #20 from RazvanN <razvan.nitu1305@gmail.com> --- *** Issue 17080 has been marked as a duplicate of this issue. *** -- |
December 09, 2022 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |razvan.nitu1305@gmail.com Severity|normal |critical --- Comment #21 from RazvanN <razvan.nitu1305@gmail.com> --- Raising severity for this issue as it is a long standing hole. -- |
December 12, 2022 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomer@weka.io --- Comment #22 from RazvanN <razvan.nitu1305@gmail.com> --- *** Issue 21195 has been marked as a duplicate of this issue. *** -- |
December 12, 2022 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 Dlang Bot <dlang-bot@dlang.rocks> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull --- Comment #23 from Dlang Bot <dlang-bot@dlang.rocks> --- @RazvanN7 created dlang/dmd pull request #14688 "Fix Issue 3720 - Taking address of member functions possible without an instance" fixing this issue: - Fix Issue 3720 - Taking address of member functions possible without an instance https://github.com/dlang/dmd/pull/14688 -- |
February 20, 2023 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 --- Comment #24 from Bolpat <qs.il.paperinik@gmail.com> --- @Zombine(In reply to ZombineDev from comment #18) > […] > > 2. After deprecation period is finished, reintroduce the &<AggregateType>.<memberFunction> but with different semantics: retunring a delegate with context pointer set to null. Why? If I want a delegate with a null pointer context and member function mfunc, today I can do ```d alias T = the-aggregate-type; auto dg = &(cast(T*)null).mfunc; ``` As an added benefit, it is absolutely clear what happens. If that is not defined behavior because of supposed null pointer dereference, we can just make it a special-case and allow it. -- |
February 20, 2023 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 dlang+issues@me.tracemymail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|dlang+issues@me.tracemymail | |.com | -- |
March 30, 2023 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 Max Samukha <maxsamukha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxsamukha@gmail.com --- Comment #25 from Max Samukha <maxsamukha@gmail.com> --- Everybody who actually tried to implement a reflection library in D would want local function (pointer) types to include the context pointer as an explicit parameter (as suggested here, for example https://github.com/dlang/dmd/pull/14688#issuecomment-1347358238). -- |
March 30, 2023 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schuetzm@gmx.net --- Comment #26 from RazvanN <razvan.nitu1305@gmail.com> --- *** Issue 13850 has been marked as a duplicate of this issue. *** -- |
May 04, 2023 [Issue 3720] Taking address of member functions possible without an instance | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=3720 --- Comment #27 from Bolpat <qs.il.paperinik@gmail.com> --- Given ```d struct T { ref int memFunc(return ref int i) return @safe immutable { return i; } } ``` I guess the only reasonable thing `typeof(&T.memFunc)` could be is: ```d ref int function(return ref immutable T, return ref int i) @safe ``` We can argue about whether the `T` parameter must be `ref`, but unless we have a mechanism to express “bind by mutable reference irrespective of value category” (this is how member functions bind the `this` object) as a parameter storage class, the only option is `ref`. Copy isn’t an option, not all types are copyable. `in` isn’t an option because it makes mutable objects `const`. DMD’s answer for `typeof(&T.memFunc)` is nonsense: ```d ref int function(return ref int i) immutable return @safe ``` Both, `immutable` and `return` make no sense on a function pointer type and do not even parse. -- |
Copyright © 1999-2021 by the D Language Foundation