On 1/28/2013 6:48 AM, Alec Teal wrote:
On 28/01/13 10:41, Jonathan Wakely wrote:
On 28 January 2013 06:18, Alec Teal wrote:
the very
nature of just putting the word "hard" before a typedef is something I find
appealing
I've already explained why that's not likely to be acceptable, because
iden
On 28/01/13 10:41, Jonathan Wakely wrote:
On 28 January 2013 06:18, Alec Teal wrote:
the very
nature of just putting the word "hard" before a typedef is something I find
appealing
I've already explained why that's not likely to be acceptable, because
identifiers are allowed before 'typedef' and
On 28 January 2013 06:18, Alec Teal wrote:
> the very
> nature of just putting the word "hard" before a typedef is something I find
> appealing
I've already explained why that's not likely to be acceptable, because
identifiers are allowed before 'typedef' and it would be ambiguous.
You need a diff
I've thought of how to phrase it.
Yes n3515 does allow more than the 'hard-typedef', they do (in part) do
the same job, but the context where you'd use one and not the other is
very clear, I like clean notations, I think that's a mathematician
thing, as I am sure you know (or have touched on) t
On 28/01/13 02:38, James Dennett wrote:
That's a cast -- an explicit request in code for a type conversion.
The fact that it's a pure compile-time operation and a no-op at
runtime has no bearing on whether it "is a cast", just as we can
static_cast beween enumerators and integers today with no
On Sun, Jan 27, 2013 at 6:19 PM, Alec Teal wrote:
> To some up again (I've kept the quotes so it can be seen what's already been
> talked about) I propose something that is almost identical to a typedef as
> it exists now, all behaviour of this hard typedef is almost identical
> except:
>
> 1) the
To some up again (I've kept the quotes so it can be seen what's already
been talked about) I propose something that is almost identical to a
typedef as it exists now, all behaviour of this hard typedef is almost
identical except:
1) the "hard" type is never implicitly 'cast' to anything else o
On Thu, 24 Jan 2013, Jeffrey Walton wrote:
How does one engage the C and C++ committees?
http://isocpp.org/forums
--
Marc Glisse
FYI:
Lawrence Crowl says "If you want your feature in mainline gcc" not I.
Also I want to be the one to do this feature, implementation.
On 24/01/13 19:49, Jeffrey Walton wrote:
On Thu, Jan 24, 2013 at 2:45 PM, Lawrence Crowl wrote:
On 1/24/13, Alec Teal wrote:
...
If you want your feat
On Thu, Jan 24, 2013 at 2:45 PM, Lawrence Crowl wrote:
> On 1/24/13, Alec Teal wrote:
>
> ...
> If you want your feature in mainline gcc, you will need to convince
> the maintainers that the feature is valuable. Likewise, if you want
> your extension in the C++ language, you will need to convinc
On 1/24/13, Alec Teal wrote:
> Did anyone read?
I can sometimes take several days to get to reading an email,
particularly when travelling.
> I hope you see how it is nothing like a strong typedef (as its
> called). To me it seems like the strong one is too similar to a
> class to be worth addin
On 24/01/13 18:45, Jonathan Wakely wrote:
On 24 January 2013 16:21, Alec Teal wrote:
That's because this has nothing to do with objects, in the paper that was
linked (called "strong typing") it implemented new types rather like
objects, "using score = public int { //definitions }; for example,
"
On 24 January 2013 16:21, Alec Teal wrote:
> That's because this has nothing to do with objects, in the paper that was
> linked (called "strong typing") it implemented new types rather like
> objects, "using score = public int { //definitions }; for example,
> "extending an int" effectively, this i
On 24/01/13 14:22, Robert Dewar wrote:
On 1/24/2013 9:10 AM, Alec Teal wrote:
Alec I am eager to see what you guys think, this is a 'feature' I've
wanted for a long time and you all seem approachable rather than the
distant compiler gods I expected.
I certainly see the point of this proposal,
On 1/24/2013 9:10 AM, Alec Teal wrote:
Alec I am eager to see what you guys think, this is a 'feature' I've
wanted for a long time and you all seem approachable rather than the
distant compiler gods I expected.
I certainly see the point of this proposal, indeed introducing
this kind of strong
Did anyone read? I hope you see how it is nothing like a strong typedef (as its
called). To me it seems like the strong one is too similar to a class to be
worth adding, especially after reading that paper, it seems like it would allow
new-php-user like behaviour of EVERYTHING IS A CLASS but wit
On 23/01/13 23:07, Lawrence Crowl wrote:
On 1/23/13, Jonathan Wakely wrote:
On 23 January 2013 09:15, Alec Teal wrote:
I was fearful of using the word attribute for fear of getting it wrong?
What
is "this part" of the compiler called
I think attributes are handled in the front end and transfo
On 1/23/13, Jonathan Wakely wrote:
> On 23 January 2013 09:15, Alec Teal wrote:
>> I was fearful of using the word attribute for fear of getting it wrong?
>> What
>> is "this part" of the compiler called
>
> I think attributes are handled in the front end and transformed into
> something in the co
On 23 January 2013 09:15, Alec Teal wrote:
> I was fearful of using the word attribute for fear of getting it wrong? What
> is "this part" of the compiler called
I think attributes are handled in the front end and transformed into
something in the compiler's "tree" data structures.
FWIW I've usua
On 23/01/13 08:55, Jonathan Wakely wrote:
On 23 January 2013 06:53, Alec Teal wrote:
Why not:
make an "optional keyword", "hard", have a meaning if before "typedef", I
suggest tokenising "hard" as a normal token (however it is processed now why
change it? I am not sure on GCCs exact grammar for
On 23 January 2013 06:53, Alec Teal wrote:
> Why not:
>
> make an "optional keyword", "hard", have a meaning if before "typedef", I
> suggest tokenising "hard" as a normal token (however it is processed now why
> change it? I am not sure on GCCs exact grammar for c languages) but if AND
> ONLY if i
On Wed, Jan 23, 2013 at 06:53:06AM +, Alec Teal wrote:
> Hello,
>
> This suggestion is obviously about typdefs and discusses a
> *theoretical* implementation, well a few of them. Anyway please do
> read this though. I'm really sorry for the poor structure, my hands
> are really cold and I'm qu
22 matches
Mail list logo
