Hi,

2013/7/23 Barend Gehrels <barend@xs4all.nl>

About size_t, I don't see the need to change behaviour w.r.t. other libraries if it was consistent between them before. Also OGC (our reference) defines Dimension as integer (probably because they have a general interface and do not have size_t).

Does OGC allow negative dimensions? If not, should we assume that they won't be used in the future?

Basically it makes sense of course, we have many template parameters w.r.t dimension already defined as size_t ...

Unless we want to give -1 (or so) a special meaning (e.g. variable dimension) but this is (as far as I remember) never discussed before.

This would probably correspond to numeric_limits<size_t>::max().

What is your actual proposal? Making core_traits::dimension of size_t? Can you send a patch before?

I was thinking about defining traits::dimension for point, point_xy and c-array to be consistent with Boost.Geometry template perameters. I thought about it because when signed dimension is compared with some unsigned value, e.g. in static_assert, some compilers complain about it.

So we could:

- leave it as it is now

- define size_t in traits only for BG types and allow ints for other types

- define size_t in traits for all types (also for Fusion and Tuple) but allow ints for user-defined types

- force size_t in core_traits

I'm not proposing anything particular and won't insist on some specific solution. What do you think about it?

Regards,
Adam