Yes, that’s possible, but beside the point.
account is still a poor parameter name inside the method, and injectedAccount is still a poor parameter name outside the method.
Yes, that’s possible, but beside the point.
account is still a poor parameter name inside the method, and injectedAccount is still a poor parameter name outside the method.
I understand that argument in general and I like the feature as I have posted previously in this thread. Though I would probably not use it in this example. Instead I would try changing it to an expression body function using elvis operators.
Whatever type of function it is, it will still have parameter names. In my opinion, the expressive naming of these is even more important in an expression body function.
In the real world, this has already been refactored away for a variety of unrelated reasons.
As I mentioned in another thread annotations may be the way to go here as it requires no change to the syntax to declare a function:
fun send(message: String,
port: ValidPort,
securityType: SecurityType,
@externalName("withDelayBeforeSending") delay: Delay) {
I’m not sure whether the feature is worth is but why not use an as ... instead. Like:
fun send(message: String,
port: ValidPort,
securityType: SecurityType,
withDelayBeforeSending: Delay = Delay.DEFAULT_DELAY as delay) { //...
actually, never mind, as wouldn’t work as the code would be valid anyway as a cast. Perhaps alias instead