[RFC] Enforce logger being available via proc-macro

[TheBlueMatt]

I was trying to explore this as an option to remove the passing of logger around everywhere in the chain and ln::channel modules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.

The advantage of this approach is that it enforces that loggers are always available (in tagged-impl blocks). It also handles passing loggers in many cases, especially method calls on self, but also inner fields that need such parameters.

The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a let x: Type = x in things like for loops (which is largely demonstrated here) or simply manually adding the logger argument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.

I don't have any feelings at all either way on this, the overhead of having to add the logger parameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.

Note that some of the code changes were move-onlys so you might have to look at a few of the commits.

[ldk-reviews-bot]

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Closing as we decided against even a simpler version of this in #4342

[TheBlueMatt]

I was trying to explore this as an option to remove the passing of logger around everywhere in the chain and ln::channel modules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.

The advantage of this approach is that it enforces that loggers are always available (in tagged-impl blocks). It also handles passing loggers in many cases, especially method calls on self, but also inner fields that need such parameters.

The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a let x: Type = x in things like for loops (which is largely demonstrated here) or simply manually adding the logger argument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.

I don't have any feelings at all either way on this, the overhead of having to add the logger parameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.

Note that some of the code changes were move-onlys so you might have to look at a few of the commits.

[ldk-reviews-bot]

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Closing as we decided against even a simpler version of this in #4342

[TheBlueMatt]

I was trying to explore this as an option to remove the passing of logger around everywhere in the chain and ln::channel modules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.

The advantage of this approach is that it enforces that loggers are always available (in tagged-impl blocks). It also handles passing loggers in many cases, especially method calls on self, but also inner fields that need such parameters.

The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a let x: Type = x in things like for loops (which is largely demonstrated here) or simply manually adding the logger argument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.

I don't have any feelings at all either way on this, the overhead of having to add the logger parameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.

Note that some of the code changes were move-onlys so you might have to look at a few of the commits.

[ldk-reviews-bot]

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Closing as we decided against even a simpler version of this in #4342

[TheBlueMatt]

I was trying to explore this as an option to remove the passing of logger around everywhere in the chain and ln::channel modules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.

The advantage of this approach is that it enforces that loggers are always available (in tagged-impl blocks). It also handles passing loggers in many cases, especially method calls on self, but also inner fields that need such parameters.

The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a let x: Type = x in things like for loops (which is largely demonstrated here) or simply manually adding the logger argument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.

I don't have any feelings at all either way on this, the overhead of having to add the logger parameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.

Note that some of the code changes were move-onlys so you might have to look at a few of the commits.

[ldk-reviews-bot]

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Closing as we decided against even a simpler version of this in #4342

[TheBlueMatt]

I was trying to explore this as an option to remove the passing of logger around everywhere in the chain and ln::channel modules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.

The advantage of this approach is that it enforces that loggers are always available (in tagged-impl blocks). It also handles passing loggers in many cases, especially method calls on self, but also inner fields that need such parameters.

The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a let x: Type = x in things like for loops (which is largely demonstrated here) or simply manually adding the logger argument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.

I don't have any feelings at all either way on this, the overhead of having to add the logger parameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.

Note that some of the code changes were move-onlys so you might have to look at a few of the commits.

[ldk-reviews-bot]

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Closing as we decided against even a simpler version of this in #4342

[TheBlueMatt]

I was trying to explore this as an option to remove the passing of logger around everywhere in the chain and ln::channel modules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.

The advantage of this approach is that it enforces that loggers are always available (in tagged-impl blocks). It also handles passing loggers in many cases, especially method calls on self, but also inner fields that need such parameters.

The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a let x: Type = x in things like for loops (which is largely demonstrated here) or simply manually adding the logger argument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.

I don't have any feelings at all either way on this, the overhead of having to add the logger parameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.

Note that some of the code changes were move-onlys so you might have to look at a few of the commits.

[ldk-reviews-bot]

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Closing as we decided against even a simpler version of this in #4342

[TheBlueMatt]

I was trying to explore this as an option to remove the passing of logger around everywhere in the chain and ln::channel modules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.

The advantage of this approach is that it enforces that loggers are always available (in tagged-impl blocks). It also handles passing loggers in many cases, especially method calls on self, but also inner fields that need such parameters.

The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a let x: Type = x in things like for loops (which is largely demonstrated here) or simply manually adding the logger argument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.

I don't have any feelings at all either way on this, the overhead of having to add the logger parameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.

Note that some of the code changes were move-onlys so you might have to look at a few of the commits.

[ldk-reviews-bot]

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Closing as we decided against even a simpler version of this in #4342

[TheBlueMatt]

I was trying to explore this as an option to remove the passing of logger around everywhere in the chain and ln::channel modules. It didn't get nearly as clean as I was hoping, so really just curious if people would prefer this or what we currently have. Since its early-RFC didn't bother to clean up the commits, they're a mess.

The advantage of this approach is that it enforces that loggers are always available (in tagged-impl blocks). It also handles passing loggers in many cases, especially method calls on self, but also inner fields that need such parameters.

The disadvantage is that its really not fully automated. Because proc-macros can only be run within the context of a single file, and because they can't have global state (due to only being called on changed files), the proc-macro can only add loggers to calls made on things with explicit types (function parameters/declared variables with explicit types/etc). As a result, you end up either having to add a let x: Type = x in things like for loops (which is largely demonstrated here) or simply manually adding the logger argument where required. In cases where the logger isn't used this feels a bit annoying, and the magic isn't, well, magic.

I don't have any feelings at all either way on this, the overhead of having to add the logger parameter or explicit type declarations in some places isn't very high, but also the win of not having to add explicit loggers doesn't feel that high to me either. The macro itself is a chunk of code, but its almost all boiler plate so not all that bad, really.

Note that some of the code changes were move-onlys so you might have to look at a few of the commits.

[ldk-reviews-bot]

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

[TheBlueMatt]

Closing as we decided against even a simpler version of this in #4342