digitalmars.D - Proposal Cast Syntax
- Stephan Wienczny (11/11) Jul 02 2004 Hallo,
- Trejkaz Xaoza (16/29) Jul 02 2004 Since I have proposed this before, I concur!
- Andrew Edwards (4/29) Jul 03 2004 Find a better way to do things so you won't need to rely so heavily on
- Trejkaz Xaoza (5/8) Jul 05 2004 That's a fine attitude if you're the only developer working on the proje...
- Norbert Nemec (3/12) Jul 05 2004 Well, but in that scenario, the beauty of the casting operator should be...
- Andrew Edwards (17/33) Jul 03 2004 Not this again! Not every D user will be pleased with every feature of
-
Trejkaz Xaoza
(7/11)
Jul 05 2004
- Derek Parnell (9/24) Jul 05 2004 ** XDL Compiler (c) 2009
- Stephan Wienczny (28/49) Jul 05 2004 Sorry but exactly that is my problem!
- Sam McCall (6/15) Jul 03 2004 The problem is it takes a type parameter, which functions can't without
Hallo, I like the new way of casting except on thing: It could be a little bit more precise. Could we have something like this: cast(BasicType, valuetocast) A cast is IMHO nothing else than a special function, why shouldn't we handle it as such? The advantage of this style can be seen if you cast classes with members: cast(BasicType,valuetocast).foo instead of (cast(BasicType)valuetocast).foo You don't need the extra parenthesis arround the cast anymore. Stephan
Jul 02 2004
Stephan Wienczny wrote:Hallo, I like the new way of casting except on thing: It could be a little bit more precise. Could we have something like this: cast(BasicType, valuetocast) A cast is IMHO nothing else than a special function, why shouldn't we handle it as such? The advantage of this style can be seen if you cast classes with members: cast(BasicType,valuetocast).foo instead of (cast(BasicType)valuetocast).fooSince I have proposed this before, I concur! It's much easier to read a cast(A, B) syntax than a cast(A) B syntax. I always figured that adding syntax merely to please the parser was bollocks, and that we should be adding syntax to please the people who have to write the damn code. :-) TX -- 'Every sufficiently advanced technology is indistinguishable from magic' - Arthur C Clarke 'Every sufficiently advanced magic is indistinguishable from technology' - Tom Graves Email: Trejkaz Xaoza <trejkaz xaoza.net> Web site: http://xaoza.net/trejkaz/ Jabber ID: trejkaz jabber.xaoza.net GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73
Jul 02 2004
Trejkaz Xaoza wrote:Stephan Wienczny wrote:Find a better way to do things so you won't need to rely so heavily on casts. Use it sparingly and you won't have as many unpleasant moments. Otherwise, suck it up!Hallo, I like the new way of casting except on thing: It could be a little bit more precise. Could we have something like this: cast(BasicType, valuetocast) A cast is IMHO nothing else than a special function, why shouldn't we handle it as such? The advantage of this style can be seen if you cast classes with members: cast(BasicType,valuetocast).foo instead of (cast(BasicType)valuetocast).fooSince I have proposed this before, I concur! It's much easier to read a cast(A, B) syntax than a cast(A) B syntax. I always figured that adding syntax merely to please the parser was bollocks, and that we should be adding syntax to please the people who have to write the damn code. :-)TX
Jul 03 2004
In article <cc59ls$1kdm$1 digitaldaemon.com>, Andrew Edwards says...Find a better way to do things so you won't need to rely so heavily on casts. Use it sparingly and you won't have as many unpleasant moments. Otherwise, suck it up!That's a fine attitude if you're the only developer working on the project. But some of us work in these mystical offices with multiple programmers in the same place, and I doubt your slice of idealism works in this scenario. :-) TX
Jul 05 2004
Trejkaz Xaoza wrote:In article <cc59ls$1kdm$1 digitaldaemon.com>, Andrew Edwards says...Well, but in that scenario, the beauty of the casting operator should be the least of your problems...Find a better way to do things so you won't need to rely so heavily on casts. Use it sparingly and you won't have as many unpleasant moments. Otherwise, suck it up!That's a fine attitude if you're the only developer working on the project. But some of us work in these mystical offices with multiple programmers in the same place, and I doubt your slice of idealism works in this scenario. :-)
Jul 05 2004
Not this again! Not every D user will be pleased with every feature of D. The majority of D users are comfortable with the current state of casts! Let it rest please! I seriously doubt the extra "()" will kill anyone. Andrew Stephan Wienczny wrote:Hallo, I like the new way of casting except on thing: It could be a little bit more precise. Could we have something like this: cast(BasicType, valuetocast) A cast is IMHO nothing else than a special function, why shouldn't we handle it as such? The advantage of this style can be seen if you cast classes with members: cast(BasicType,valuetocast).foo instead of (cast(BasicType)valuetocast).foo You don't need the extra parenthesis arround the cast anymore.class foo { void* data; } void main() { foo bar = new foo; bar.data = cast(void*)100; int data; data = cast(int)bar.data; // didn't need it anyway! printf("%d",data); }Stephan
Jul 03 2004
In article <cc58tf$1jmp$1 digitaldaemon.com>, Andrew Edwards says...Not this again! Not every D user will be pleased with every feature of D. The majority of D users are comfortable with the current state of casts! Let it rest please! I seriously doubt the extra "()" will kill anyone.<sarcasm> While we're at it, I propose we introduce a new syntax for all functions, where we use a new set of parentheses for each parameter. int result = do_your_stuff(1)(a)("fish"); I seriously doubt the extra "()" will kill anyone... </sarcasm>
Jul 05 2004
On Mon, 5 Jul 2004 07:13:55 +0000 (UTC), Trejkaz Xaoza wrote:In article <cc58tf$1jmp$1 digitaldaemon.com>, Andrew Edwards says...** XDL Compiler (c) 2009 ** [82893/1] Multiple Thyntacth Errorth ** The Thource Line Thould Thay ... (((int)(result)) (=) ((do_your_stuff)((1)(a)("fish"))(;))) -- Derek Melbourne, Australia 5/Jul/04 5:24:03 PMNot this again! Not every D user will be pleased with every feature of D. The majority of D users are comfortable with the current state of casts! Let it rest please! I seriously doubt the extra "()" will kill anyone.<sarcasm> While we're at it, I propose we introduce a new syntax for all functions, where we use a new set of parentheses for each parameter. int result = do_your_stuff(1)(a)("fish"); I seriously doubt the extra "()" will kill anyone... </sarcasm>
Jul 05 2004
Andrew Edwards wrote:Not this again! Not every D user will be pleased with every feature of D. The majority of D users are comfortable with the current state of casts! Let it rest please! I seriously doubt the extra "()" will kill anyone. Andrew class foo { void* data; } void main() { foo bar = new foo; bar.data = cast(void*)100; int data; data = cast(int)bar.data; // didn't need it anyway! printf("%d",data); }Sorry but exactly that is my problem! I've got code that looks like this: class Token { } class OperatorToken { int value; } Token currenttoken; ... ... switch (cast(OperatorToken)currenttoken.value) { 1: 2: default: } If I try to compile this I get this error: parser.d(594): no property 'value' for type 'Token' All I'm trying to suggest is to have something like this: CASTEXPRESSION = "cast" "(" IDENTIFIER "," IDENTIFIERLIST ")"; ^^ target type ^^ variable This should be quite easy to parse and understand. I said function in my last post because it looks like such not because it is one. Stephan
Jul 05 2004
Stephan Wienczny wrote:Hallo, I like the new way of casting except on thing: It could be a little bit more precise. Could we have something like this: cast(BasicType, valuetocast) A cast is IMHO nothing else than a special function, why shouldn't we handle it as such?The problem is it takes a type parameter, which functions can't without templates. So the function syntax should look like cast!(BasicType)(value)... just like in C++. You end up with just as many parentheses ;) Sam
Jul 03 2004