[suggestion] changing the return type for events

[primal copper]

I've only noticed the MessageCreate event but the return type for it is Promise<void>. I suggest changing it to Promise<any> because Promise<void> makes validating stuff and replying impossible. For example:

client.on("messageCreate", async Message => {
 let answer = Message.content;
 if (answer !== "cow") return await Message.channel.send("wrong answer"); // oops an error
})

Since I am returning a Promise<Message> i'll get a error saying that void and Message do not match. And that is why I suggest this, I do not want to use a more complicated to re-read validate statement

For example I can do this to go about the error:

client.on("messageCreate", async Message => {
 let answer = Message.content;
 if (answer !== "cow") {
  await Message.channel.send("wrong answer"); // oops an error
  return;
 }
})

but that is just unnecessary effort and unnecessary complication

[vast topaz]

Seems like a contradiction. Events shouldn't return anything because nothing will look at them

[primal copper]

yeah since nothing will look at them, returning anything matters not

[vast topaz]

And no it doesn't make validating and replying impossible. Simply do not return it

[harsh ginkgo]

i don't think the second is more complicated. it just follows the logical standard of returning

[vast topaz]

No that's an incorrect assumption

[primal copper]

but i want my code to stop at there, that is the point of validation

[harsh ginkgo]

then do it like in your second exmaple. its literally just one more line of code

[vast topaz]

Or that^

[primal copper]

"its just one line of code"

[harsh ginkgo]

yes that is indeed what i said

[primal copper]

what do u mean return void ...? u mean set the type?

[vast topaz]

void makes the expression void

[primal copper]

look, my event can have as many validations are it requires, it is easy to say that when theres only 1 or 2 lines of validation, but what if i had 10 or even 20. And what if something in my validation went wrong and i would need to reread a what could be a 10 line validation turned into 30 lines

[harsh ginkgo]

i have no idea what you are saying tbh

[primal copper]

but how would i include my message send in it

[harsh ginkgo]

why do you want to include your message. including it has literally zero benefit

[primal copper]

ill give u a visual example

what can be done:

if (...) return await message...;
if (...) return await message...;
if (...) return await message...;
if (...) return await message...;
if (...) return await message...;

what needs to be done:

if (...) {
 await message...;
 return;
}
if (...) {
 await message...;
 return;
}
if (...) {
 await message...;
 return;
}
if (...) {
 await message...;
 return;
}
if (...) {
 await message...;
 return;
}

[harsh ginkgo]

....or you just do else if

[primal copper]

what difference would that make

[harsh ginkgo]

and even so, there is nothing wrong with doing it the second way

[primal copper]

visually speaking

[harsh ginkgo]

it wouldnt trigger the next if block, therefore not giving you any reason to return.

[primal copper]

"And what if something in my validation went wrong and i would need to reread a what could be a 10 line validation turned into 30 lines"

[harsh ginkgo]

you could probably also do if (...) {await message...; return;}

all in one line

[primal copper]

sure but i find the first example to be more easily to read

especially when you're debugging and when you're frustrated

[harsh ginkgo]

are you complaining about having to look through 30 lines of code to find a bug? i don‘t think developing is for you then.

[harsh ginkgo]

if you are so easily frustrated that looking at something slightly less pretty when debugging is a problem for you, you shouldn’t do coding

[primal copper]

now you're just bein unreasonable, "you dont like to manually build everything from scratch? then you're not suited to be an engineer"

convenience is what i am arguing about

[harsh ginkgo]

convenience is not the name of the game, type safety is.

[peak flicker]

Promise<any> is less safe for the implementation - its why void is preferred

[primal copper]

how does changing from void to any will make anything less safe

[harsh ginkgo]

don‘t use typescript or disable the typescript feature for return types if you are more concerned with convenience

[peak flicker]

that being said Promise<unknown> would be as safe and also solve your issue, probably.

[primal copper]

the return value is not being used

[primal copper]

"disable the typescript feature for return types if you are more concerned with convenience" then whats the point of using typescript lmao

[harsh ginkgo]

the point of typescript is being inconvenienced in favor of safer code :P

[primal copper]

...yes

[peak flicker]

this is such an unproductive conversation

[primal copper]

i agree

[peak flicker]

then dont hold it

[primal copper]

because the other party is being unreasonable

[peak flicker]

ignore bad takes if they're repeatedly brought up

anyways, as I was pointing out

[harsh ginkgo]

so stop whining about being inconvenienced lol

[peak flicker]

I'm strongly against using any here because it's not quite correct for the internal implementation

but I believe unknown would be the correct middle ground

it allows you to return anything in the callback while the internal impl can't use the return value unsafely

[primal copper]

fuck off and go learn the definition of "open mind"

[peak flicker]

so much for ignoring them

[primal copper]

the value returned by the callback is being used?

[peak flicker]

well, it shouldn't be is the thing

[harsh ginkgo]

wow just going to insult me then alright lol

[peak flicker]

thats why the type is void

it makes it impossible to use it

of course EE is implemented in plain JS so really it doesn't matter but its a type correctness thing

callbacks like this should always return a type that doesn't allow arbitrary usage

[primal copper]

well if changing to unkown allows me to validate more conveniently then i'd have no complains

[peak flicker]

I believe unknown should accomplish this, it just wasn't a thing when those types were written

[primal copper]

yea i tested it and unknown works

[zealous rain]

just do return void await Message.channel.send(…)

[vast topaz]

That was already suggested

[charred tiger]

Not going to change it