On Monday, 24 December 2012 at 15:36:47 UTC, Jonathan M Davis
wrote:
I believe that C# did something similar. It would certainly
solve the question
of package's virtuality quite nicely and wouldn't change any
existing code,
just allow for those who want virtual package functions to have
them.
Andrei Alexandrescu wrote:
On 12/24/12 6:20 AM, Jacob Carlborg wrote:
On 2012-12-24 01:11, Walter Bright wrote:
1. what access means at module scope
2. at class scope
3. at template mixin scope
4. backwards compatibility
5. overloading at each scope level and the interactions with access
On Friday, December 28, 2012 16:52:32 Andrei Alexandrescu wrote:
On 12/28/12 4:45 PM, Jonathan M Davis wrote:
On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
Has anyone started a DIP on this? Let's not let things scroll away from
the institutional memory.
I've only
On 12/24/12 6:20 AM, Jacob Carlborg wrote:
On 2012-12-24 01:11, Walter Bright wrote:
1. what access means at module scope
2. at class scope
3. at template mixin scope
4. backwards compatibility
5. overloading at each scope level and the interactions with access
6. I'd also throw in getting rid
On Sunday, 23 December 2012 at 19:55:15 UTC, Jonathan M Davis
wrote:
On Sunday, December 23, 2012 12:20:01 Tobias Pfaff wrote:
So the nice thing to have here would be a standardized
interface to the
compiler, or even compiler as a library, with direct data
access to this
kind of information.
On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
Has anyone started a DIP on this? Let's not let things scroll away from
the institutional memory.
I've only gotten as far as thinking about it and leaving the relevant e-mails
marked as unread.
- Jonathan M Davis
On 12/28/12 4:45 PM, Jonathan M Davis wrote:
On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
Has anyone started a DIP on this? Let's not let things scroll away from
the institutional memory.
I've only gotten as far as thinking about it and leaving the relevant e-mails
marked
On Friday, 28 December 2012 at 21:12:48 UTC, Andrei Alexandrescu
wrote:
On 12/24/12 6:20 AM, Jacob Carlborg wrote:
On 2012-12-24 01:11, Walter Bright wrote:
1. what access means at module scope
2. at class scope
3. at template mixin scope
4. backwards compatibility
5. overloading at each
On 12/22/2012 1:29 AM, Jérôme M. Berger wrote:
Walter Bright wrote:
It's that way in C++ mainly so that it doesn't make the already complex
overloading system even more so. And in 25 years of working with C++,
I've never seen this make anyone's list of horrible things about C++.
Andrei Alexandrescu:
Sorry for the late reply.
I think this is a reframing we should shun because it switches
the focus from what is the usefulness of this to what is the
difficulty of putting up with it.
Jonathan was (rightfully) presenting the implementation problems,
so I have had the
On Sunday, December 23, 2012 23:41:35 Jonathan M Davis wrote:
Also, making the compiler take the most accessible function is _wrong_. In
the example above, if bar were in the same module as S, it would then call
the public foo, whereas if it were in another module, you'd get an error
(assuming
Walter Bright wrote:
On 12/23/2012 4:03 AM, Jérôme M. Berger wrote:
Because C++ *can* hide symbols from other modules with the
anonymous namespace. D has no equivalent.
Everyone here has raised some good points. But this isn't a simple
issue, so I suggest getting together and preparing a
Jonathan M Davis wrote:
On Sunday, December 23, 2012 16:11:02 Walter Bright wrote:
6. I'd also throw in getting rid of the protected access attribute
completely, as I've seen debate over that being a useless idea
Really? I'm shocked at that. It's necessary for stuff like NVI if
private
Andrei Alexandrescu wrote:
On 12/22/12 3:21 AM, Walter Bright wrote:
It's that way in C++ mainly so that it doesn't make the already
complex overloading system even more so. And in 25 years of working
with C++, I've never seen this make anyone's list of horrible things
about C++.
I think
Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that
apples should be peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void foo(float);
}
void
On 2012-12-24 01:11, Walter Bright wrote:
1. what access means at module scope
2. at class scope
3. at template mixin scope
4. backwards compatibility
5. overloading at each scope level and the interactions with access
6. I'd also throw in getting rid of the protected access attribute
Jonathan M Davis wrote:
The plan is to have a lexer and parser for D in the standard library, which
would greatly simplify creating tools that did this sort of thing. We'd
probably already have the lexer portion (I was working on it earlier this
year), but I got insanely busy in real life.
On Monday, December 24, 2012 12:20:35 Jacob Carlborg wrote:
On 2012-12-24 01:11, Walter Bright wrote:
1. what access means at module scope
2. at class scope
3. at template mixin scope
4. backwards compatibility
5. overloading at each scope level and the interactions with access
6. I'd
On 12/24/12 06:20, Martin Nowak wrote:
On 12/23/12 03:35, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples
should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void
Walter Bright wrote:
On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
Pretty much every time that this issue comes up, people are surprised
by the
fact that private symbols aren't hidden and pretty much no one wants
them to
be in overload sets.
This has been discussed before, and the same
Jonathan M. Davis wrote:
A lint-like tool is free to point them out for you, and maybe an IDE could
highlight them, but actually making the compiler consider unused variables to
be either a warning or an error would be an incredibly bad idea for D - on
top
of the fact that it would be
On Sunday, 23 December 2012 at 12:20:01 UTC, Tobias Pfaff wrote:
So the nice thing to have here would be a standardized
interface to the
compiler, or even compiler as a library, with direct data
access to this
kind of information.
Yes the concept of what a complier is, how how it is
On Sunday, December 23, 2012 12:20:01 Tobias Pfaff wrote:
So the nice thing to have here would be a standardized interface to the
compiler, or even compiler as a library, with direct data access to this
kind of information.
The plan is to have a lexer and parser for D in the standard library,
I'd like to add that I have programmed with google Go for some
time and moved to D for various reasons. It is true that unused
imports and variables may be a hint that something was done
wrong, or forgotten, and a review might be desirable. I am all
for being warned about this. However, it is
Never mind my last question. Found that it stands for: uniform
function call syntax. Now I am going to look into what that means
and how it affects the no accessibility but visibility thingy.
Ok so it's the feature that allows you to write something like
myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.
I'd like to know if there is any functionality provided by having
private functions/methods being visible? Does it mean you can
override them in your module (for
Ok so it's the feature that allows you to write something like
myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.
I'd like to know if there is any functionality provided by having
private functions/methods being visible? Does it mean you can
override them in your module (for
On Sunday, December 23, 2012 21:36:34 Phil Lavoie wrote:
Never mind my last question. Found that it stands for: uniform
function call syntax. Now I am going to look into what that means
and how it affects the no accessibility but visibility thingy.
It means that any free function can be called
On Sunday, December 23, 2012 21:47:13 Phil Lavoie wrote:
Ok so it's the feature that allows you to write something like
myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.
I'd like to know if there is any functionality provided by having
private functions/methods being
private is _always_ module scope.
Ooops I meant private functions inside a module. I was wondering
if that would be allowed:
module a;
public auto aFunc( T )( T t ) { cantSeeMe( t ); }
private auto canSeeMe( SomeType t ) { ... }
module b;
import a;
alias a.canSeeMe canSeeMe
public auto
On Sunday, December 23, 2012 22:12:17 Phil Lavoie wrote:
private is _always_ module scope.
Ooops I meant private functions inside a module. I was wondering
if that would be allowed:
module a;
public auto aFunc( T )( T t ) { cantSeeMe( t ); }
private auto canSeeMe( SomeType t ) { ... }
In this case, I am convinced that there is no use of having the
no accessibility but visibility particularity, because I cannot
find any reason for it to stay like that (feature/exploit wise).
On the other hand, I don't work on the compiler and I have no
idea of what difficulties in would
On Sunday, December 23, 2012 23:34:41 Phil Lavoie wrote:
In this case, I am convinced that there is no use of having the
no accessibility but visibility particularity, because I cannot
find any reason for it to stay like that (feature/exploit wise).
On the other hand, I don't work on the
On 12/23/2012 4:03 AM, Jérôme M. Berger wrote:
Because C++ *can* hide symbols from other modules with the
anonymous namespace. D has no equivalent.
Everyone here has raised some good points. But this isn't a simple issue, so I
suggest getting together and preparing a DIP. A DIP should
On Sunday, December 23, 2012 16:11:02 Walter Bright wrote:
6. I'd also throw in getting rid of the protected access attribute
completely, as I've seen debate over that being a useless idea
Really? I'm shocked at that. It's necessary for stuff like NVI if private
functions aren't virtual as
On 12/23/12 04:02, Jonathan M Davis wrote:
In addition, in my experience, it's quite rare for classes to have public and
private functions with the same name, meaning that you just don't hit this
problem very often.
Having public and private constructors is a common idiom.
On 12/23/12 03:35, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples
should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void
On Monday, December 24, 2012 06:20:04 Martin Nowak wrote:
On 12/23/12 03:35, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples
should be
peeled because oranges should.
Given, in C++:
On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
But we _want_ that. The fact that inaccessible functions are even considered
in overload sets is horrible. That's precisely the problem. No inaccessible
functions should be in overload sets. Otherwise, simply adding a private
function to a module
On 12/21/2012 8:38 PM, Jonathan M Davis wrote:
The reason it is that way is to avoid having it behave gratuitously
differently than how visibility works within classes and structs.
??? I don't see anything here that would become different between user-defined
types and modules.
All we're
Jonathan M Davis:
but generally the worst that they'll do is create slight
overhead because of the cost of default initializing them.
I don't care about that overhead, because the optimizer stages of
compilers take care of removing it in many cases, that's not one
of the main points of
On Saturday, December 22, 2012 09:30:15 bearophile wrote:
Jonathan M Davis:
but generally the worst that they'll do is create slight
overhead because of the cost of default initializing them.
I don't care about that overhead, because the optimizer stages of
compilers take care of removing
On Saturday, December 22, 2012 00:21:33 Walter Bright wrote:
On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
But we _want_ that. The fact that inaccessible functions are even
considered in overload sets is horrible. That's precisely the problem. No
inaccessible functions should be in
Jonathan M Davis:
You're basically asking for a feature to be added to the
language so that the compiler will be able to tell you where
your code is messy without complaining about legitimate code,
_and_ your suggestion would make the legitimate code messier.
Here you are right only in
On Saturday, December 22, 2012 09:53:48 bearophile wrote:
Jonathan M Davis:
You're basically asking for a feature to be added to the
language so that the compiler will be able to tell you where
your code is messy without complaining about legitimate code,
_and_ your suggestion would make
Walter Bright wrote:
On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
But we _want_ that. The fact that inaccessible functions are even
considered
in overload sets is horrible. That's precisely the problem. No
inaccessible
functions should be in overload sets. Otherwise, simply adding a
12/22/2012 12:21 PM, Walter Bright пишет:
On 12/21/2012 11:23 PM, Jonathan M Davis wrote:
But we _want_ that. The fact that inaccessible functions are even
considered
in overload sets is horrible. That's precisely the problem. No
inaccessible
functions should be in overload sets. Otherwise,
On 12/22/2012 09:21 AM, Walter Bright wrote:
On 12/21/2012 8:38 PM, Jonathan M Davis wrote:
The reason it is that way is to avoid having it behave gratuitously
differently than how visibility works within classes and structs.
??? I don't see anything here that would become different between
On 12/22/12 3:30 AM, bearophile wrote:
Legitimate uses of unused variables are mostly in library code, or user
code similar to library code. Adding to those variable definitions a
@used is fast and perfectly easy. It's not a jumping through hoops.
I think this is a reframing we should shun
On 12/22/12 3:21 AM, Walter Bright wrote:
It's that way in C++ mainly so that it doesn't make the already complex
overloading system even more so. And in 25 years of working with C++,
I've never seen this make anyone's list of horrible things about C++.
I think this is a fallacious argument
On Saturday, 22 December 2012 at 08:47:44 UTC, Jonathan M Davis
wrote:
Pretty much every time that this issue comes up, people are
surprised by the
fact that private symbols aren't hidden and pretty much no one
wants them to
be in overload sets. I think that you're the only one that I've
seen
On Saturday, December 22, 2012 20:11:25 Rob T wrote:
I had no idea this was going on. If private symbols are not
really private then they shouldn't be called private because that
is very misleading and can lead to subtle mistakes that will be
difficult to understand and avoid.
When I've
On Saturday, 22 December 2012 at 20:24:54 UTC, Jonathan M Davis
wrote:
They're private in the same way that they're private in C++.
They're
inaccessible (i.e. can't be called), but they're not actually
hidden.
Accessibility is only taken into account after overloading has
been sorted
out.
On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
Pretty much every time that this issue comes up, people are surprised by the
fact that private symbols aren't hidden and pretty much no one wants them to
be in overload sets.
This has been discussed before, and the same people wanted private
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void foo(float);
}
void bar()
{
S s;
s.foo(1.0f);
On 12/22/2012 6:35 PM, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void
On Saturday, December 22, 2012 18:35:47 Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples
should be peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
On 12/21/2012 11:19 PM, Jonathan M Davis wrote:
but generally the worst that
they'll do is create slight overhead because of the cost of default
initializing them.
This is not an issue. An optimization called dead assignment elimination has
been in compilers since the 1980's, including dmd.
On 12/22/2012 1:04 AM, Jonathan M Davis wrote:
Walter has completely convinced me with regards to how bad an idea
compiler warnings are.
Wow!
On 12/22/12 9:29 PM, Walter Bright wrote:
On 12/22/2012 12:46 AM, Jonathan M Davis wrote:
Pretty much every time that this issue comes up, people are surprised
by the
fact that private symbols aren't hidden and pretty much no one wants
them to
be in overload sets.
This has been discussed
On Sunday, 23 December 2012 at 02:35:46 UTC, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes
that apples should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
On Sunday, 23 December 2012 at 04:43:27 UTC, Rob T wrote:
For dlopen() the default behavior is RTLD_LOCAL, which makes
all symbols from loaded libs private to their respective libs.
This is the default behavior to ensure predictable execution
behaviors, and it's the same default behavior that
On 12/23/2012 03:35 AM, Walter Bright wrote:
On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
I think this is a fallacious argument because it concludes that apples
should be
peeled because oranges should.
Given, in C++:
struct S
{
public:
void foo(int);
private:
void
On Sunday, December 23, 2012 05:56:07 Timon Gehr wrote:
structs and classes are utterly irrelevant at this point of the discussion.
That's mostly true, but UFCS probably makes it so that structs and classes are
in the same boat as free functions in modules are. Without UFCS, it's a
relatively
On 12/21/2012 06:41 AM, Walter Bright wrote:
D has an excellent module system.
... modulo the private symbol clash issue. For all I know it is
deliberate, which is embarrassing. Other than obviously breaking
modularity, it severely restricts the usefulness of symbol
disambiguation
Walter Bright:
another large source of irritation if unused imports are errors.
In Go even unused variables are *errors* :-)
D has an excellent module system. No, I don't think Go or
anyone else has a better one.
I think D module system is a primitive tool compared to (S)ML
module
12/21/2012 12:44 PM, Timon Gehr пишет:
On 12/21/2012 06:41 AM, Walter Bright wrote:
D has an excellent module system.
... modulo the private symbol clash issue. For all I know it is
deliberate, which is embarrassing. Other than obviously breaking
modularity, it severely restricts the
On Friday, December 21, 2012 12:57:10 Dmitry Olshansky wrote:
+1. It never made any sense to me that private is visible but not
accessible. A carryover from C++ I guess (but there we just hide stuff
out of the header file, use awful internal namespaces etc.).
It also makes stuff like private
On 12/21/2012 12:58 AM, bearophile wrote:
Walter Bright:
D has an excellent module system. No, I don't think Go or anyone else has a
better one.
I think D module system is a primitive tool compared to (S)ML module system.
http://en.wikipedia.org/wiki/Standard_ML#Module_system
Then why did
Walter Bright:
Then why did you bother with the Go module system?
The Go and D module systems are comparable, while the SML module
system is something quite different and another (higher) level.
Bye,
bearophile
On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
Walter Bright:
another large source of irritation if unused imports are
errors.
In Go even unused variables are *errors* :-)
D has an excellent module system. No, I don't think Go or
anyone else has a better one.
I think D
On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
Walter Bright:
another large source of irritation if unused imports are
errors.
In Go even unused variables are *errors* :-)
This is a tricky one. On one hand, it *is* a useful way to catch
errors, but on the other it's a
On Friday, 21 December 2012 at 13:19:32 UTC, Peter Alexander
wrote:
On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
Walter Bright:
another large source of irritation if unused imports are
errors.
In Go even unused variables are *errors* :-)
This is a tricky one. On one
jerro:
SML modules are something entirely different from D modules.
Yep. (That's what I have said to Walter).
If you want SML module like functionality in D,
I don't. I (did) want modules to have the same name as their
files.
Bye,
bearophile
On 12/21/12, bearophile bearophileh...@lycos.com wrote:
Walter Bright:
another large source of irritation if unused imports are errors.
In Go even unused variables are *errors* :-)
There was a long blost post somewhat recently (well, it might be from
this year at least) where the author
Peter Alexander:
This is a tricky one. On one hand, it *is* a useful way to
catch errors, but on the other it's a constant source of
irritation when you are tinkering with code during
development/debugging.
I agree. I think a simple way to solve this problem is to put
unused variables
On 12/21/12, Walter Bright newshou...@digitalmars.com wrote:
snip
Walter, can you verify if this is or isn't a bug:
.\main.d
.\foo.d
main.d:
module main;
import foo;
void main() { test(); }
foo.d:
module bar;
void test() { }
This is OK:
$ dmd -c main.d foo.d
main.d(2): Error: module bar
I remember having very weird issues with rdmd when module is
called main. May be this one is similar?
On Friday, 21 December 2012 at 14:52:27 UTC, Andrej Mitrovic
wrote:
On 12/21/12, Walter Bright newshou...@digitalmars.com wrote:
snip
Walter, can you verify if this is or isn't a bug:
On Friday, December 21, 2012 14:19:32 Peter Alexander wrote:
On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
Walter Bright:
another large source of irritation if unused imports are
errors.
In Go even unused variables are *errors* :-)
This is a tricky one. On one hand,
Jonathan M Davis:
It also doesn't work with stuff like RAII and a lot of
conditional compilation.
Particularly with eponymous templates, it's _very_ common to
have unused
variables. Warnings or errors for unused variables would be
highly detrimental to D.
A warning for unused variables will
On Friday, December 21, 2012 18:46:20 bearophile wrote:
Jonathan M Davis:
It also doesn't work with stuff like RAII and a lot of
conditional compilation.
Particularly with eponymous templates, it's _very_ common to
have unused
variables. Warnings or errors for unused variables would be
On 12/21/2012 06:59 PM, Jonathan M Davis wrote:
A lint-like tool is free to point them out for you, and maybe an IDE could
highlight them, but actually making the compiler consider unused variables to
be either a warning or an error would be an incredibly bad idea for D - on top
of the fact that
On Friday, December 21, 2012 20:29:43 Joseph Rushton Wakeling wrote:
On 12/21/2012 06:59 PM, Jonathan M Davis wrote:
A lint-like tool is free to point them out for you, and maybe an IDE could
highlight them, but actually making the compiler consider unused variables
to be either a warning
On Friday, 21 December 2012 at 19:37:58 UTC, Jonathan M Davis
wrote:
Not only are there perfectly legitimate uses for having used
variables (e.g.
RAII) […]
Destructors with side effects could simply count as a use –
problem solved.
[…] change
the semantics of programs (due to have it
On Friday, December 21, 2012 20:58:02 David Nadlinger wrote:
[…] change
the semantics of programs (due to have it affects conditional
compilation),
Warnings should not affect conditional compilation, even if the
user has warnings as errors turned on. The whole difference of
warnings
On 12/21/2012 4:16 AM, bearophile wrote:
Walter Bright:
Then why did you bother with the Go module system?
The Go and D module systems are comparable, while the SML module system is
something quite different and another (higher) level.
From your wikipedia link, the SML module system is
On 12/21/2012 5:40 AM, eles wrote:
However, it is reasonable to include something like strictness
levels as part of the compiler? (think gcc with MISRA-C
integrated).
Having multiple languages via a switch leads to much confusion and cost. I try
to avoid such as much as possible.
On 12/21/2012 5:19 AM, Peter Alexander wrote:
On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
Walter Bright:
another large source of irritation if unused imports are errors.
In Go even unused variables are *errors* :-)
This is a tricky one. On one hand, it *is* a useful way
On 12/21/2012 6:52 AM, Andrej Mitrovic wrote:
It seems the compiler doesn't complain about invalid import statements
when it tries to find the module via its import path. Bug?
I'd have to say that's a bug.
On Friday, 21 December 2012 at 20:33:47 UTC, Jonathan M Davis
wrote:
If we didn't have -w,
then we could use warnings for stuff which was probably but not
definitively
wrong and which was okay to force people to change […] But
because
of -w, you can't […]
I don't think this is a valid
On Friday, December 21, 2012 12:41:42 Walter Bright wrote:
On 12/21/2012 5:40 AM, eles wrote:
However, it is reasonable to include something like strictness
levels as part of the compiler? (think gcc with MISRA-C
integrated).
Having multiple languages via a switch leads to much confusion
On 12/21/2012 1:40 PM, Jonathan M Davis wrote:
I would point out that -w does exactly that thanks to conditional compilation
and compile-time introspection.
I know, and there are threads here where I opposed warnings very strongly.
On Friday, 21 December 2012 at 22:25:51 UTC, Walter Bright wrote:
On 12/21/2012 1:40 PM, Jonathan M Davis wrote:
I would point out that -w does exactly that thanks to
conditional compilation
and compile-time introspection.
I know, and there are threads here where I opposed warnings
very
On 12/21/2012 2:33 PM, David Nadlinger wrote:
On Friday, 21 December 2012 at 22:25:51 UTC, Walter Bright wrote:
On 12/21/2012 1:40 PM, Jonathan M Davis wrote:
I would point out that -w does exactly that thanks to conditional compilation
and compile-time introspection.
I know, and there are
On 12/21/2012 12:44 AM, Timon Gehr wrote:
... modulo the private symbol clash issue. For all I know it is deliberate,
which is embarrassing. Other than obviously breaking modularity, it severely
restricts the usefulness of symbol disambiguation (which it makes necessary when
it should not be),
On 12/22/2012 02:44 AM, Walter Bright wrote:
On 12/21/2012 12:44 AM, Timon Gehr wrote:
... modulo the private symbol clash issue. For all I know it is
deliberate,
which is embarrassing. Other than obviously breaking modularity, it
severely
restricts the usefulness of symbol disambiguation
On Friday, December 21, 2012 14:25:28 Walter Bright wrote:
On 12/21/2012 1:40 PM, Jonathan M Davis wrote:
I would point out that -w does exactly that thanks to conditional
compilation and compile-time introspection.
I know, and there are threads here where I opposed warnings very strongly.
On Friday, December 21, 2012 17:44:43 Walter Bright wrote:
On 12/21/2012 12:44 AM, Timon Gehr wrote:
... modulo the private symbol clash issue. For all I know it is
deliberate,
which is embarrassing. Other than obviously breaking modularity, it
severely restricts the usefulness of symbol
On Friday, December 21, 2012 22:12:31 David Nadlinger wrote:
On Friday, 21 December 2012 at 20:33:47 UTC, Jonathan M Davis
wrote:
If we didn't have -w,
then we could use warnings for stuff which was probably but not
definitively
wrong and which was okay to force people to change […]
On Saturday, 22 December 2012 at 04:21:06 UTC, Jonathan M Davis
wrote:
I tend to agree that warnings were a bad idea and that they
should never have
been introduced, if nothing else, because I don't think that
it's ever good
practice to leave warnings in your code, making them almost the
same
1 - 100 of 113 matches
Mail list logo
