(1) The methods for providing estimates on Param and ImageParam are "set_" prefixed, but the methods for Func are not.
(2) For Input<Buffer<>> you must use .set_bounds_estimate() but for Output<Buffer<>> you must use .estimate(); if you understand the implementation underneath, this makes sense, but is weird and counterintuitive IMHO
(3) For Func, it would be convenient to have an API for providing an estimate for nth-dimension, for (e.g.) a defined Func that is passed to you where you know the dimension count but not necessarily the Var names. (You can approximation this with Func::args()[] but it's ugly.)
Strawman proposal:
Unify all "provide-estimate" functions with a "set" prefix and all "retrieve-estimate" functions with a "get" prefix.
Special-case Output<Buffer<>> to use .set_boundsestimate() instead of [set]estimate()
Add Func::estimate_dim(int n, Expr min, Expr extent) as syntactic sugar
Concerns I have from some experimentation.
(1) The methods for providing estimates on Param and ImageParam are "set_" prefixed, but the methods for Func are not. (2) For Input<Buffer<>> you must use .set_bounds_estimate() but for Output<Buffer<>> you must use .estimate(); if you understand the implementation underneath, this makes sense, but is weird and counterintuitive IMHO (3) For Func, it would be convenient to have an API for providing an estimate for nth-dimension, for (e.g.) a defined Func that is passed to you where you know the dimension count but not necessarily the Var names. (You can approximation this with Func::args()[] but it's ugly.)
Strawman proposal:
Func::estimate_dim(int n, Expr min, Expr extent)
as syntactic sugar