Those are both good ideas

@colesbury I ran into a lot of trouble around ambiguous constructors for ArrayRef. Having two functions with ArrayRef<double> and ArrayRef<int> causes {1, 2, 3} to be ambiguous because it doesn't know whether to call ArrayRef<double>({1, 2, 3}) or ArrayRef<int>({1, 2, 3}). Of course, only one would be preferred during overload resolution, but the compiler can't think that far (the ambiguity comes from knowing whether to invoke the constructor of ArrayRef<double> or ArrayRef<int>.

Instead I've made the methods templated. This way, at least you can write at::tensor<int64_t>({1, 2, 3}). It's still not as nice as ScalarList, which solved the whole ambiguity problem, but I guess it doesn't incur a copy and is less code ...

@pytorchbot retest this please

This deserves some tests. Currently, if you call an unsupported method you'll get a linker error which isn't ideal. In my local testing, at::native::tensor({1, 2, 3, 4}) also did not work.

Here are some use cases that I think should work:

std::vector<int32_t> data(...);
at::tensor(data);

at::tensor({1, 2, 3, 4})
at::tensor({1.0, 2.5, 3.5})

I would suggest the following to avoid the ambiguous overloads:

tensor(ArrayRef<int64_t> values)
tensor(ArrayRef<int32_t> values)
tensor(ArrayRef<int16_t> values)
tensor(ArrayRef<int8_t> values)
tensor(ArrayRef<uint8_t> values)
tensor(ArrayRef<float> values)
tensor(ArrayRef<double> values)
tensor(ArrayRef<Half> values)

tensor(initializer_list<int> values)
tensor(initializer_list<float> values)
tensor(initializer_list<double> values)

I would suggest that the ArrayRef<T> overloads preserve the type T of their values if no dtype is given. For example, the int32_t overload should create an int tensor, not a long tensor.

I would suggest that the initializer_list overloads default to kLong for <int> and the default tensor type for float and double. Since the default tensor type isn't in ATen yet, you could just assume kFloat for now.

@colesbury @ezyang please take another look. I used the FORALL_SCALAR_TYPES macro and it works very well now. I'm omitting half support because it would require a more complicated separate implementation, and we don't need it urgently.

Added lots of tests.

My local test case:

std::vector<int> v = {1, 2, 3, 5, 6};
  std::vector<float> w = {1, 2, 3, 5, 6};
  std::cout << at::tensor(123.456) + 0.5 << std::endl;
  std::cout << at::tensor({1, 2, 3}) + 0.5 << std::endl;
  std::cout << at::tensor(v) + 0.5 << std::endl;
  std::cout << at::tensor(w) + 0.5 << std::endl;
  std::cout << at::tensor({1.0, 2.0, 3.0}) + 0.5 << std::endl;
  std::cout << at::tensor({1.5, 2.6, 3.7}, at::kInt) + 0.5 << std::endl;
  std::cout << at::tensor(123, at::kByte) + 0.5 << std::endl;

prints

 123.9560
[ CPUDoubleTensor{1} ]
 1
 2
 3
[ CPUIntTensor{3} ]
 1
 2
 3
 5
 6
[ CPUIntTensor{5} ]
 1.5000
 2.5000
 3.5000
 5.5000
 6.5000
[ CPUFloatTensor{5} ]
 1.5000
 2.5000
 3.5000
[ CPUDoubleTensor{3} ]
 1
 2
 3
[ CPUIntTensor{3} ]
 123
[ CPUByteTensor{1} ]

@pytorchbot retest this please

Hey @goldsborough, is there any particular reason you didn't go the "add overloads for initializer list" route?

Isn't that the effectively what I did? There's one overload of initializer_list per scalar type. This way there is 0 ambiguity and everything works. Or did you mean something else?

So, I got deceived by my C++ heuristic that says that if you can do it with overloads, don't use a template; I couldn't actually construct an example where it mattered if tensor was templated or not. So... carry on!