I was assuming aliases would only be present at parsing time. I to
prefer iX notation, I like to be explicit. Yet I can imagine a lot of
users, who don't care about bits and bytes, they just want int. Or they
want to make IDL look more like Java/C# ;)
I'd not try to detect all 'typedef i32 int' constructs, as next step
would be to detect all keywords of all supported languages... Which
might be a good idea, but would require a lot of work, especially while
adding new lang. But maybe 'reserved type and members names' is doable...
@Stig: About errors: I think, that problem appears in generated code for
langs which have typedef constructs. Like C or C++, where such IDL leads
to something like "typedef int32_t int" which tries to redefine C keyword...
-KG
On 01.12.2014 15:26, Stig Bakken wrote:
FWIW, I agree with Randy. There is value to being able to directly
compare two type names through simple equality, with aliases you will
get situations where you need code like "are_these_types_the_same(t1,
t2)".
On Mon, Dec 1, 2014 at 2:21 PM, Randy Abernethy <r...@apache.org> wrote:
One of the things I love about Thrift is its simple IDL. No aliases
just simple self describing types (i8, i16, etc). We presently have
one keyword for each feature of the IDL. I think the Pandora's box
analogy is a good one. It is hard work keeping things simple.
On Mon, Dec 1, 2014 at 12:09 AM, Stig Bakken <s...@zedge.net> wrote:
Out of curiosity, what kinds of errors did you see from this?
- Stig
On Mon, Dec 1, 2014 at 1:18 AM, Jens Geyer <jensge...@hotmail.com> wrote:
Hi *,
I have found people multiple times doing things like this, ending up with
strange errors.
typedef i32 int
What about making it legal and allowing int as an built-in alias for i32?
Or should we add some kind of warning instead?
Or would either one of these just open pandora’s box?
Have fun,
JensG
