On 8/13/2015 6:12 AM, Dicebot wrote:
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely sure if this
behavior can be relied upon (or it is just a side effect of imports
On 08/20/2015 01:25 AM, Walter Bright wrote:
I want to use it as an import hygiene idiom but not entirely sure if this
behavior can be relied upon (or it is just a side effect of imports being
implemented as aliases currently).
It has nothing to do with aliases.
Imports work the same way as
On 08/15/2015 06:15 PM, Dicebot wrote:
On Friday, 14 August 2015 at 20:12:43 UTC, Timon Gehr wrote:
On 08/14/2015 08:57 PM, Dicebot wrote:
Ok, let's stop for a minute and make sure we are on the same thread
here. Because you seem to argue something I have never said or at least
intended to
On Friday, 14 August 2015 at 20:12:43 UTC, Timon Gehr wrote:
On 08/14/2015 08:57 PM, Dicebot wrote:
Ok, let's stop for a minute and make sure we are on the same
thread
here. Because you seem to argue something I have never said or
at least
intended to say.
...
OK. This is my view: The
On 08/14/2015 08:57 PM, Dicebot wrote:
Ok, let's stop for a minute and make sure we are on the same thread
here. Because you seem to argue something I have never said or at least
intended to say.
...
OK. This is my view: The sub-thread was started with the claim that the
module system is
Ok, let's stop for a minute and make sure we are on the same
thread here. Because you seem to argue something I have never
said or at least intended to say.
So, my basic statements:
1. I don't like default D import semantics but I am not proposing
to change it
2. I like Rust default import
On Thursday, 13 August 2015 at 16:22:04 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis
wrote:
You can get that behavior with static imports in D, but having
to use the whole import path while referencing symbols gets
ugly fast.
Check example again, you are
On 08/14/2015 05:55 PM, Dejan Lekic wrote:
On Thursday, 13 August 2015 at 16:22:04 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis wrote:
You can get that behavior with static imports in D, but having to use
the whole import path while referencing symbols gets
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely sure
if this behavior can be relied upon (or it is just a side effect
of imports being implemented as aliases currently).
On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely
sure if this behavior can be relied upon (or it is just a
On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely
sure if this behavior can be relied upon (or it is just a
On 08/13/2015 03:42 PM, Jonathan M Davis wrote:
On Thursday, 13 August 2015 at 13:12:44 UTC, Dicebot wrote:
Right now this works:
``D
struct Std
{
public import std.stdio;
}
void main()
{
Std.writeln(Nice!);
}
```
I want to use it as an import hygiene idiom but not entirely sure if
this
On 13-Aug-2015 16:56, Timon Gehr wrote:
[snip]
It has nothing to do with the import being public. This works:
---
struct Std{
import std.stdio;
}
void main(){
Std.writeln(Nice!);
}
---
(It also works if main and Std are defined in different modules.)
but I also don't see how this
As long as imports are not hygienic, this trick is useful. I
didn't find it useful in a language with hygienic imports (C#).
On Thursday, 13 August 2015 at 16:37:00 UTC, Jonathan M Davis
wrote:
Well, that's better than requiring the full import path, but
requiring _any_ module name is just plain annoying IMHO. If I
were okay with that I wouldn't be doing stuff like
using namespace std;
in all of my .cpp files -
On Thursday, 13 August 2015 at 16:40:31 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 16:37:00 UTC, Jonathan M Davis
wrote:
Well, that's better than requiring the full import path, but
requiring _any_ module name is just plain annoying IMHO. If I
were okay with that I wouldn't be doing
On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis
wrote:
Matter of scale. At some point of application size maintenance
cost become much higher than development costs - and problems
of name clashes become more important than any extra typing
annoyance.
Well, if name clashes
On Thursday, 13 August 2015 at 17:32:33 UTC, Dmitry Olshansky
wrote:
On 13-Aug-2015 20:17, Jonathan M Davis wrote:
On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis
wrote:
Matter of scale. At some point of application size
On Thursday, 13 August 2015 at 17:51:06 UTC, Jonathan M Davis
wrote:
But the private symbols affecting the public API is just plain
embarrassing and definitely makes the problem _far_ worse.
- Jonathan M Davis
It's worse than embarassing. Every symbol added, public or
private, must be
On 08/13/2015 06:22 PM, Dicebot wrote:
On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis wrote:
You can get that behavior with static imports in D, but having to use
the whole import path while referencing symbols gets ugly fast.
Check example again, you are only required to use
On Thursday, 13 August 2015 at 16:40:31 UTC, Dicebot wrote:
Matter of scale. At some point of application size maintenance
cost become much higher than development costs - and problems
of name clashes become more important than any extra typing
annoyance.
In my C++ projects such using
On 13-Aug-2015 20:17, Jonathan M Davis wrote:
On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis wrote:
Matter of scale. At some point of application size maintenance cost
become much higher than development costs - and
On Thursday, 13 August 2015 at 16:24:56 UTC, Timon Gehr wrote:
static import greetings=phrases.english.greetings;
?
http://forum.dlang.org/post/szaaakmavraxatkrf...@forum.dlang.org
How is this relevant? Does Rust support it?
Relevant as explanation why I don't consider aliased imports a
On Thursday, 13 August 2015 at 16:22:04 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis
wrote:
You can get that behavior with static imports in D, but having
to use the whole import path while referencing symbols gets
ugly fast.
Check example again, you are
On Thursday, 13 August 2015 at 17:09:11 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 17:06:18 UTC, Jonathan M Davis
wrote:
Matter of scale. At some point of application size
maintenance cost become much higher than development costs -
and problems of name clashes become more important
On 08/13/2015 06:36 PM, Dicebot wrote:
On Thursday, 13 August 2015 at 16:24:56 UTC, Timon Gehr wrote:
static import greetings=phrases.english.greetings;
?
http://forum.dlang.org/post/szaaakmavraxatkrf...@forum.dlang.org
How is this relevant? Does Rust support it?
Relevant as explanation
On Thursday, 13 August 2015 at 15:53:16 UTC, anonymous wrote:
On Thursday, 13 August 2015 at 15:29:19 UTC, Dicebot wrote:
struct Something
{
public import a;
}
void main() { Something.foo(); }
What's wrong with `import Something = a;`? Bugs?
Works only with a single import:
import
On Thursday, 13 August 2015 at 15:49:10 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 15:40:12 UTC, Timon Gehr wrote:
You know about static imports, right?
Yes, as well as about renamed and selective ones ;)
Problem with static imports is that they are all-or-nothing.
And in our
On Thursday, 13 August 2015 at 15:59:46 UTC, Timon Gehr wrote:
On 08/13/2015 05:49 PM, Dicebot wrote:
On Thursday, 13 August 2015 at 15:40:12 UTC, Timon Gehr wrote:
You know about static imports, right?
Yes, as well as about renamed and selective ones ;)
Problem with static imports is that
On 08/13/2015 06:19 PM, Dicebot wrote:
On Thursday, 13 August 2015 at 15:59:46 UTC, Timon Gehr wrote:
On 08/13/2015 05:49 PM, Dicebot wrote:
On Thursday, 13 August 2015 at 15:40:12 UTC, Timon Gehr wrote:
You know about static imports, right?
Yes, as well as about renamed and selective ones
On Thursday, 13 August 2015 at 16:19:29 UTC, Jonathan M Davis
wrote:
You can get that behavior with static imports in D, but having
to use the whole import path while referencing symbols gets
ugly fast.
Check example again, you are only required to use the plain
module name, not fully
On Thursday, 13 August 2015 at 13:44:50 UTC, rsw0x wrote:
And we're back to namespaces : )
Not really.
This is namespace:
-
module a;
struct Something
{
static void foo() {}
}
module b;
import a;
void main() { Something.foo(); }
-
This is import hygiene:
-
module a;
void
On 08/13/2015 05:29 PM, Dicebot wrote:
On Thursday, 13 August 2015 at 13:44:50 UTC, rsw0x wrote:
And we're back to namespaces : )
Not really.
This is namespace:
-
module a;
struct Something
{
static void foo() {}
}
module b;
import a;
void main() { Something.foo(); }
-
This
On Thursday, 13 August 2015 at 15:40:12 UTC, Timon Gehr wrote:
You know about static imports, right?
Yes, as well as about renamed and selective ones ;)
Problem with static imports is that they are all-or-nothing. And
in our projects it is common to have module names with 5 nested
packages
On 08/13/2015 05:35 PM, Dicebot wrote:
On Thursday, 13 August 2015 at 13:42:42 UTC, Jonathan M Davis wrote:
I confess that I don't particularly like that this is legal (and I
think that public imports tend to get a bit hinky because of the fact
that they create aliases), and I'm not quite sure
On 08/13/2015 05:34 PM, Dicebot wrote:
In any case, I guess we agree that this idiom should work for public
imports, but not for non-public ones (so the current behaviour with
non-public imports is accepts-invalid, but Dicebot's code should be
fine)?
I am very curious to learn official
On 08/13/2015 05:49 PM, Dicebot wrote:
On Thursday, 13 August 2015 at 15:40:12 UTC, Timon Gehr wrote:
You know about static imports, right?
Yes, as well as about renamed and selective ones ;)
Problem with static imports is that they are all-or-nothing.
(Which is an arbitrary restriction
On Thursday, 13 August 2015 at 15:53:16 UTC, anonymous wrote:
On Thursday, 13 August 2015 at 15:29:19 UTC, Dicebot wrote:
struct Something
{
public import a;
}
void main() { Something.foo(); }
What's wrong with `import Something = a;`? Bugs?
Even better: feature.
On Thursday, 13 August 2015 at 13:56:24 UTC, Timon Gehr wrote:
It has nothing to do with the import being public. This works:
---
struct Std{
import std.stdio;
}
void main(){
Std.writeln(Nice!);
}
---
(It also works if main and Std are defined in different
modules.)
Ah, I thought
On Thursday, 13 August 2015 at 13:42:42 UTC, Jonathan M Davis
wrote:
I confess that I don't particularly like that this is legal
(and I think that public imports tend to get a bit hinky
because of the fact that they create aliases), and I'm not
quite sure how you could use it form import
On Thursday, 13 August 2015 at 15:29:19 UTC, Dicebot wrote:
struct Something
{
public import a;
}
void main() { Something.foo(); }
What's wrong with `import Something = a;`? Bugs?
41 matches
Mail list logo
