Support promises in addition to continuation-passing

[ghost]

My reasoning for this is to support promises on Model methods. Maybe even better idea would be to enable this in some higher configuration.
When promisify: true all the methods would be wrapped with bluebird's Promise.promisify(). I assume this could be done without side effects in internals.compileModel within index.js.

The other idea is to support both at the same time as it's done in Joi.validate

When used without a callback, this function returns a Promise-like object that can be used as a promise

[cdhowie]

I agree that natively supporting promises would be nice. I'd suggest instead that the configuration parameter be a promise factory. By default it would be global.Promise but could be replaced with require('bluebird') or require('Q') to use a different promise implementation.

[pdeschen]

Promise support would be a nice addition. Why not go the AWS sdk route where each function supports promises as

function(params).promise()...

[cdhowie]

I think it makes more sense to have the callback argument be optional. If not provided, asynchronous methods will return a promise instead.

[pdeschen]

I would have agreed to directly return a promise on unprovided callback for a pristine new library but for backward compatibility I think it would be safer to explicitly opt in for a promise.

Reason: I think there could be existing cases out in the field where callbacks are not provided which could then potentially lead to UnhandledPromiseRejectionWarning

[cdhowie]

I don't consider additional warnings to break backwards compatibility, as the program will function the same way in every other respect. In fact, the warnings could be very useful in cases where programs should be handling errors, but are silently ignoring them.

[Darkhogg]

Any idea if/when this will be done or how can we help??