On Thursday, 11 July 2013 at 20:15:52 UTC, Namespace wrote:
The whole situation looks strange. If you can change both
files, than it is unclear what made you to write such
inconsistent code. If you can change only one of them, then it
should be adjusted to another (meaning importing external
Could it be something to do with purity, perhaps?
On 2013-07-12 00:45, JS wrote:
I believe the issue is that isFinalFunction requires an actual function
symbol but I'm passing it a string?
How can I get this to work?
Have you tried using a mixin?
__traits(isFinalFunction, mixin(className ~ . ~ member));
--
/Jacob Carlborg
On 2013-07-11 20:22, Namespace wrote:
[snip]
Does anyone have any advice?
Who is supposed to access these enums? Can you put it in a separate
module but in the same package with package protection?
--
/Jacob Carlborg
On Friday, 12 July 2013 at 06:38:54 UTC, Jacob Carlborg wrote:
On 2013-07-12 00:45, JS wrote:
I believe the issue is that isFinalFunction requires an actual
function
symbol but I'm passing it a string?
How can I get this to work?
Have you tried using a mixin?
__traits(isFinalFunction,
On Friday, 12 July 2013 at 06:38:54 UTC, Jacob Carlborg wrote:
On 2013-07-12 00:45, JS wrote:
I believe the issue is that isFinalFunction requires an actual
function
symbol but I'm passing it a string?
How can I get this to work?
Have you tried using a mixin?
__traits(isFinalFunction,
BTW, the error is
testmodule.d(14): Error: undefined identifier main
which suggests that the template can't find the module. I can
import the module and it will work fine but this seems a bit
circular. I will try and mixin the module to solve my original
problem but still need to figure out
On Friday, 12 July 2013 at 06:54:40 UTC, Jacob Carlborg wrote:
On 2013-07-11 20:22, Namespace wrote:
[snip]
Does anyone have any advice?
Who is supposed to access these enums? Can you put it in a
separate module but in the same package with package protection?
No. Both modules are in
On Thu, 11 Jul 2013 19:22:10 +0100, Namespace rswhi...@googlemail.com
wrote:
I have a style question, because a friend of mine has a similar problem
currently and I have no good advice for him.
Let's assume we have this classes:
class MyClass {
public:
enum A {
On 2013-07-12 09:25, JS wrote:
BTW, the error is
testmodule.d(14): Error: undefined identifier main
Where does main come from?
which suggests that the template can't find the module. I can import the
module and it will work fine but this seems a bit circular. I will try
and mixin the module
On Friday, 12 July 2013 at 11:28:19 UTC, Jacob Carlborg wrote:
On 2013-07-12 09:25, JS wrote:
BTW, the error is
testmodule.d(14): Error: undefined identifier main
Where does main come from?
which suggests that the template can't find the module. I can
import the
module and it will work
On Thursday, 11 July 2013 at 19:37:31 UTC, dnewbie wrote:
On Thursday, 11 July 2013 at 12:58:42 UTC, Chris wrote:
I have a DLL written in D I load into a Python application via
ctypes like so:
lib = CDLL(mydll)
The DLL loads and can be used no problem. However, once the
DLL is discarded of
On Friday, 12 July 2013 at 13:15:34 UTC, Chris wrote:
On Thursday, 11 July 2013 at 19:37:31 UTC, dnewbie wrote:
On Thursday, 11 July 2013 at 12:58:42 UTC, Chris wrote:
I have a DLL written in D I load into a Python application
via ctypes like so:
lib = CDLL(mydll)
The DLL loads and can be
On 2013-07-11, 20:22, Namespace wrote:
What should he do?
As far as I can see he has 3 options:
1. An external file with the enum information. Both classes would import
it and could use the same enum. But he cannot change the API, so this is
no real option.
2. Change test1 into this:
Go and Rust seem to have been able to dispense with the parens in
for loops, is this something that would be possible to do in D or
are there parsing and grammatical reasons not to do this?
ixid:
Go and Rust seem to have been able to dispense with the parens
in for loops, is this something that would be possible to do in
D or are there parsing and grammatical reasons not to do this?
Go has chosen a different syntax. I don't think D syntax of for
loops can change now...
Bye,
On Friday, 12 July 2013 at 19:44:43 UTC, bearophile wrote:
ixid:
Go and Rust seem to have been able to dispense with the parens
in for loops, is this something that would be possible to do
in D or are there parsing and grammatical reasons not to do
this?
Go has chosen a different syntax. I
ixid:
If curly brackets were required where parens were omitted
what would prevent such a syntax in D?
Maybe nothing, beside lot of programmers that want the freedom
to omit curly brackets :-)
Bye,
bearophile
On Friday, 12 July 2013 at 20:02:46 UTC, bearophile wrote:
ixid:
If curly brackets were required where parens were omitted
what would prevent such a syntax in D?
Maybe nothing, beside lot of programmers that want the
freedom to omit curly brackets :-)
Bye,
bearophile
Similarly what are
On Friday, 12 July 2013 at 20:30:59 UTC, bearophile wrote:
ixid:
Similarly what are D user's potential issues with Go-like
semi-colon rules? And would this be possible as a subset of
current D code?
Such changes will not happen even in D4. Walter is strongly
against the idea of optional
On 7/12/13 5:38 PM, ixid wrote:
On Friday, 12 July 2013 at 20:30:59 UTC, bearophile wrote:
ixid:
Similarly what are D user's potential issues with Go-like semi-colon
rules? And would this be possible as a subset of current D code?
Such changes will not happen even in D4. Walter is strongly
ixid:
Similarly what are D user's potential issues with Go-like
semi-colon rules? And would this be possible as a subset of
current D code?
Such changes will not happen even in D4. Walter is strongly
against the idea of optional semicolons, on the base that
semicolons help the parser, so
On 2013-07-12, 22:38, ixid wrote:
On Friday, 12 July 2013 at 20:30:59 UTC, bearophile wrote:
ixid:
Similarly what are D user's potential issues with Go-like semi-colon
rules? And would this be possible as a subset of current D code?
Such changes will not happen even in D4. Walter is
They are not issues in Go, but Walter is strongly against
optional semicolons, as bearophile said. Me and others (like
you) like optional semicolons, but since Walter doesn't and
it's his language, that will not change.
I personally understand much better the code without
semicolons, like in
I'm not sure how much of a problem it is, especially given that
Go has a
strict style guide, but the objection has come up that these
two are
very different:
if i f() {
g()
}
and
if i f()
{
g()
}
In the second case, a semicolon is inserted on the same line as
the
On 7/12/13 1:46 PM, ixid wrote:
They are not issues in Go, but Walter is strongly against optional semicolons,
as bearophile said.
Me and others (like you) like optional semicolons, but since Walter doesn't and
it's his language,
that will not change.
I personally understand much better the
On Fri, Jul 12, 2013 at 05:51:21PM -0700, Brad Roberts wrote:
On 7/12/13 1:46 PM, ixid wrote:
[...]
It seems a pity that D is achieving such power and elegance in some
areas while failing to take on some of the syntactic beauty that is
within reach. The ultimate language would look something
As long as the syntax is
not *too* ugly (*cough*C++ templates*cough*) isn't the
*semantics* more
important? A pretty language that has limited expressiveness is
useless;
a powerful language that's a bit ugly in syntax isn't any less
powerful
because of it.
T
What is the cost of
On Sat, Jul 13, 2013 at 03:19:04AM +0200, ixid wrote:
As long as the syntax is not *too* ugly (*cough*C++ templates*cough*)
isn't the *semantics* more important? A pretty language that has
limited expressiveness is useless; a powerful language that's a bit
ugly in syntax isn't any less
On Saturday, July 13, 2013 06:42:57 QAston wrote:
On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:
Yes, I don't expect anyone to change their opinion though
frankly the anti-groups opinions feel more like attachment to
the status quo than something that's evidently and demonstrably
On Saturday, 13 July 2013 at 04:56:19 UTC, Jonathan M Davis wrote:
On Saturday, July 13, 2013 06:42:57 QAston wrote:
On Friday, 12 July 2013 at 20:46:21 UTC, ixid wrote:
Yes, I don't expect anyone to change their opinion though
frankly the anti-groups opinions feel more like attachment to
On Saturday, 13 July 2013 at 04:42:58 UTC, QAston wrote:
Also, i don't know what's wrong with parens - 2 additional
keystrokes? I didn't see a for loop i a long time - ranges +
foreach are everywhere. And foreach is 4 chars more to type
than for :P.
Replying to myself, but well, this is
32 matches
Mail list logo
