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
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 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
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 of
On Sun, Jan 27, 2013 at 6:19 PM, Alec Teal a.t...@warwick.ac.uk 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
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
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)
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
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
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
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 is what I
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 1/24/13, Alec Teal a.t...@warwick.ac.uk 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
On Thu, Jan 24, 2013 at 2:45 PM, Lawrence Crowl cr...@googlers.com wrote:
On 1/24/13, Alec Teal a.t...@warwick.ac.uk 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++
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 cr...@googlers.com wrote:
On 1/24/13, Alec Teal
On Thu, 24 Jan 2013, Jeffrey Walton wrote:
How does one engage the C and C++ committees?
http://isocpp.org/forums
--
Marc Glisse
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 it is before a
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 c
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 usually
On 1/23/13, Jonathan Wakely jwakely@gmail.com 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
On 23/01/13 23:07, Lawrence Crowl wrote:
On 1/23/13, Jonathan Wakely jwakely@gmail.com 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
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 quite
22 matches
Mail list logo