Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sun, 29 Jul 2018 at 20:25, Walter Bright via Digitalmars-d wrote: > > On 7/29/2018 7:50 PM, Nicholas Wilson wrote: > > No it doesn't. > > I meant that you can today "reopen" namespace scopes by placing them in > separate > modules. That's not the same thing... you can create a _different one_ with the same name in a different module. If you import both modules, the namespaces conflict, so it's definitely not 'reopening' it as such. You need to make sure to not name the namespace when specifying symbols when you import 2 C++ modules, because it becomes ambiguous.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/29/2018 7:50 PM, Nicholas Wilson wrote: No it doesn't. I meant that you can today "reopen" namespace scopes by placing them in separate modules. You can (today) also "reopen" namespace scopes by placing them in separate mixin templates, or struct declarations. I posted examples.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sun., 29 Jul. 2018, 7:20 pm Walter Bright via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On 7/29/2018 1:45 PM, Manu wrote:
> > There's no way you'll get a bug report from someone complaining they
> > can't multiply define symbols in the same scope. That's common sense.
>
> But then you cannot interface with this C++ code:
>
> namespace ab { void foo(); }
> namespace cd { void foo(); }
>
> Why would you find this acceptable?
>
ab.d
--
module ab;
extern(C++, "ab") void foo();
cd.d
--
module cd;
extern(C++, "cd") void foo();
Perfect!
In 20 years, I've never seen 2 namespaces in the same file. And if the C++
code were like that, I'd break it into separate modules anyway, because
that's what every D programmer would expect.
Normal D module divisions map perfectly to every C++ program I've ever
wanted to bind to yet.
Conversely, single namespacs spread across many files appear all the time,
and the current solution with disconnected namespaces scoped beneath the
modules is extremely un-C++-like and problematic.
> You must have missed my other post:
> [...]
No, I feel like you've missed literally every post I've ever made on the
topic.
We ***do not want to use extern(C++) to scope and organise code***! That's
what modules are for.
D has modules, and they're good, and that's how we want to organise our
code. I feel like I've conveyed that clearly.
It doesn't need to be harder than that. We're perfectly happy with the way
D works in every other case. We don't want 'cases' here.
I can't understand your arguments saying the simpler design (ie, D modules)
are complex, and cause for a torrent of bug reports.
I haven't seen any bug reports about D modules making it impossible to
organise code, and if that were true, then we have a serious problem with
D's module design which carries WAAAY beyond extern(C++).
I understand you're ideologically attached to this idea, and that's fine; I
don't want to take anything away from you.
We have what already exists, that can't go away now, but please just give
us string namespaces as a mangle-only option. Not only will I shut up about
it forever, but we will also be able to specify namespaces that conflict
with D keywords, and also organise our modules just like all other D code
ever.
>
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 30 July 2018 at 02:53:43 UTC, Nicholas Wilson wrote:
On Monday, 30 July 2018 at 02:15:57 UTC, Walter Bright wrote:
On 7/29/2018 1:45 PM, Manu wrote:
There's no way you'll get a bug report from someone
complaining they
can't multiply define symbols in the same scope. That's
common sense.
But then you cannot interface with this C++ code:
namespace ab { void foo(); }
namespace cd { void foo(); }
Why would you find this acceptable?
But you can if ab and cd are in different modules. The point is
to decouple the mangling from the scope, leave the scope to D's
module system, leave the mangling to extern(C++, "foo")
Not that this alleviates Alita's issues at all.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 30 July 2018 at 02:15:57 UTC, Walter Bright wrote:
On 7/29/2018 1:45 PM, Manu wrote:
There's no way you'll get a bug report from someone
complaining they
can't multiply define symbols in the same scope. That's common
sense.
But then you cannot interface with this C++ code:
namespace ab { void foo(); }
namespace cd { void foo(); }
Why would you find this acceptable?
But you can if ab and cd are in different modules. The point is
to decouple the mangling from the scope, leave the scope to D's
module system, leave the mangling to extern(C++, "foo")
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 30 July 2018 at 02:09:37 UTC, Walter Bright wrote:
On 7/29/2018 1:52 PM, Manu wrote:
On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
wrote:
[...]
so that a straight C++ namespace => D module hierarchy mapping
would probably be required in the general case:
```
// cppns/package.d
module cppns;
extern(C++, "cppns") { void foo(); }
// cppns/nested/package.d
module cppns.nested;
extern(C++, "cppns") extern(C++, "nested") { void foo(); }
```
It's beautiful!
(but I added the quotes in there for you; without quotes is
existing
defined behaviour which introduces scopes)
But that works now, I suggested it, and you didn't find it
acceptable !!?!!
No it doesn't. You missed
(but I added the quotes in there for you; without quotes is
existing
defined behaviour which introduces scopes)
With the above extern(C++, "cppns") (note the quotes) defines the
mangling, the D module defines the scope.
This is consistent with e.g. how the druntime bindings to C's
standard library (with extern(C)) are used with extern(C) only
affects the mangling, not introducing a scope, only that with
extern(C++) you can have multiple things in different namespaces
all called the same thing, so you actually need the scope as well
as the mangling.
[Issue 19127] UDAs seem to be raw AST nodes rather than expressions
https://issues.dlang.org/show_bug.cgi?id=19127
--- Comment #3 from | ---
Oh hey, more fun:
---
module test2;
import std.stdio;
struct S
{
this(int i) { writeln(i); }
}
size_t print(string s = "hello world")
{
writeln(s);
return s.length;
}
size_t x(size_t i) { return i + 1; }
struct A { static uint x; }
string s = "";
int i;
@(std.stdio)
@(new Object)
@(x(4))
@(S(1))
@(A.x)
@(A.x++)
@print
int j;
pragma(msg, __traits(getAttributes, j).stringof);
---
With the pragma(msg), this compiles. Without, it doesn't. Weee!
--
[Issue 19127] UDAs seem to be raw AST nodes rather than expressions
https://issues.dlang.org/show_bug.cgi?id=19127 --- Comment #2 from | --- Correction: non-CTFEable expressions besides function calls without arguments cannot be used as UDAs. Some of my testing was incorrect. Had B4S1L3 on IRC been more professional or friendly, I might have seen that sooner. --
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/29/2018 1:52 PM, Manu wrote:
On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
wrote:
[...]
so that a straight C++ namespace => D module hierarchy mapping
would probably be required in the general case:
```
// cppns/package.d
module cppns;
extern(C++, "cppns") { void foo(); }
// cppns/nested/package.d
module cppns.nested;
extern(C++, "cppns") extern(C++, "nested") { void foo(); }
```
It's beautiful!
You must have missed my other post:
Here's another method:
--
extern (C++, ns) { int foo() { return 1; } }
mixin template X()
{
extern (C++, ns) { int bar() { return 2; } }
}
mixin X!() x;
---
and another:
-
extern (C++, ns) { int foo() { return 1; } }
struct S
{
extern (C++, ns) { int bar() { return 2; } }
}
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/29/2018 2:44 PM, Seb wrote: FYI: this doesn't error as of now, Right, but also you cannot specify which will be called.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/29/2018 1:45 PM, Manu wrote:
There's no way you'll get a bug report from someone complaining they
can't multiply define symbols in the same scope. That's common sense.
But then you cannot interface with this C++ code:
namespace ab { void foo(); }
namespace cd { void foo(); }
Why would you find this acceptable?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/29/2018 1:52 PM, Manu wrote:
On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
wrote:
[...]
so that a straight C++ namespace => D module hierarchy mapping
would probably be required in the general case:
```
// cppns/package.d
module cppns;
extern(C++, "cppns") { void foo(); }
// cppns/nested/package.d
module cppns.nested;
extern(C++, "cppns") extern(C++, "nested") { void foo(); }
```
It's beautiful!
(but I added the quotes in there for you; without quotes is existing
defined behaviour which introduces scopes)
But that works now, I suggested it, and you didn't find it acceptable !!?!!
Newbie: out-of-source builds with "dub"?
Before starting with D programming, most of my projects have configured their build systems with Autotools or CMake, and git for source control. With those systems, it's usually considered best practice to store all files generated during configuration and build to be located outside of the source tree. My usual modus operandi is: 1. check out the project into some directory "foo". 2. create another directory "foo.build", somewhere outside of "foo". 3. "cd foo.build" 4. Run some configuration script/file located in "foo", to generate "foo.build/Makefile". 5. Run "make". I've started playing with "dub", and it *seems* to assume that you want the files generated during the build process to reside directly inside your checked-out source tree. Is that true? And if so, am I fighting dub's design by attempting out-of-source builds?
Re: Question about template argument matching with alias this
On Sunday, 29 July 2018 at 20:51:45 UTC, Alex wrote:
Do you mean something like this?
[...]
Yeah, I know that it possible to implement the template like
this, but that is not the point here. I would like to know why it
does not work the way I described it. To me it seems very
strange, that `S : T` has different semantics in `is` expressions
and as template parameters.
My actual problem is the following: I would like to use the
dependency injection framework poodinis [1] in conjuction with
the mocking capabilities from unit-threaded [2]. My code would
look something like the following:
```
import poodinis : DependencyContainer;
import unit_threaded.mock : mock;
interface SomeInterface
{
}
unittest
{
auto myMock = mock!SomeInterface;
alias MockedType = typeof(myMock)
auto container = new shared DependencyContainer;
container.register!(SomeInterface,
MockedType)().existingInstance(myMock);
/* ... */
}
```
The problem with this is that register has the signature
described above, i.e. register(T, S : T)() and that the mock
template from unit-threaded is actually implemented by a struct
which is "alias this"ed (how do you call that...? :D) to a class
which is derived from the mocked interface. This means I run
exactly into the problem I described in the first post.
Now I could ask the author of poodinis to remove the restriction
on the template parameters for register, but it actually
perfectly makes sense to have that restriction, because we are
registering a concrete type as an abstract type.
I also had a quick look at the implementation of mock, which
seems to be quite complicated already. So I fear that changing
this implementation to using a derived class directly is unlikely
to happen.
So I am back to my question: Why do we have this strange
behavior? All compiler version on run.dlang.io behave like that,
so I suppose there is some reason for this...?
[0] https://github.com/mbierlee/poodinis
[1] https://github.com/atilaneves/unit-threaded
Re: trait to get the body code of a function?
So, does anyone want to take up the challenge of writing such a function that can safely get the function body? I guess D CTFE'able D parser would be required and basically use what I've given above. I've seen a few lexers around but not messed with them. This will at least fill in a gap.
Re: How to best implement a DSL?
On Saturday, 28 July 2018 at 14:59:31 UTC, Robert M. Münch wrote:
Hi, I'm seeking for ideas/comments/experiences how to best
implement a DSL in D.
What I would like to do is something like this:
... my D code ...
my-dsl {
... my multi-line DSL code ...
trade 100 shares(x) when (time < 20:00) and timingisright()
}
... my D code ...
Some things that circle in my head:
* Can the D parser somehow be missued for a DSL? So I can skip
all the generic features for types etc.?
* I could use a PEG grammer for parsing the DSL, but this leads
to quite some overhead for a tiny DSL.
* For static DSL code I would like to use CTFE to convert it
into D code
* Does this requires a CTFE compatible PEG parser tookit?
* Could I somehow call an external program during compilation
which gets the DSL block as input and returns D code?
* For dynamic DSL code I think I need to create something like
an interpreter
* How can I reference D variables from DSL code? Is there a
lookup meachnisam or do I have to create a dictonary?
* Is it possible to populate such a dictonary via CTFE?
Why not simply turn your dsl in to D code? If it is pre-existing
you'll need a simple mapping.
trade 100 shares(x) when (time < 20:00) and timingisright()
could be written any number of ways:
trade(100.shares(x).when("time < 20.0", "&", "timingisright()")
Simply construct your grammar around D types and use UFSC,
members, and ranges and then either use it directly or map to it.
If the grammar is relatively small but simply lots of variations
then it should be rather easy(e.g., if you just have trade,
shares, and when then it would be very easy and the work would in
implementation.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 29 July 2018 at 08:28:08 UTC, Walter Bright wrote:
On 7/29/2018 1:15 AM, Manu wrote:
All we're asking for is that C++ namespaces do **nothing**
except affect the mangling.
If I do that, the next bug report will be:
extern (C++, "ab") { void foo(); }
extern (C++, "cd") { void foo(); } // Error, foo() is already
declared
foo(); // which one gets called?
The reason namespaces were added to C++ is to not have such
name collisions. Namespaces in C++ introduce a scope. D cannot
interoperate with this without introducing a scope as well.
FYI: this doesn't error as of now, but with
https://github.com/dlang/dmd/pull/8429 it will.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 29 July 2018 at 08:28:08 UTC, Walter Bright wrote:
On 7/29/2018 1:15 AM, Manu wrote:
All we're asking for is that C++ namespaces do **nothing**
except affect the mangling.
If I do that, the next bug report will be:
extern (C++, "ab") { void foo(); }
extern (C++, "cd") { void foo(); } // Error, foo() is already
declared
foo(); // which one gets called?
mangle (C++, "ab") { void foo(); }
mangle (C++, "cd") { void foo(); } // Error, foo() is already
That would not require any changes to extern and there would be
no sensible argument for trying to define foo twice.
Re: Question about template argument matching with alias this
On Sunday, 29 July 2018 at 16:43:08 UTC, Johannes Loher wrote:
I have a question about template argument matching in
combination with implicit conversion and alias this. Consider
the following code:
interface SomeInterface
{
}
class SomeClass : SomeInterface
{
}
struct SomeStruct
{
SomeClass someClass;
alias someClass this;
}
template isSuperType(T, S : T)
{
enum isSuperType = is(SomeStruct : SomeInterface);
}
void main()
{
static assert(is(SomeStruct : SomeInterface));
static assert(isSuperType!(SomeInterface, SomeStruct)); //
why does the template not match?
}
The question is, why does the template declaration not match?
Thanks for your help!
Do you mean something like this?
´´´
interface SomeInterface {}
class SomeClass : SomeInterface {}
struct SomeStruct
{
SomeClass someClass;
alias someClass this;
}
template isSuperType(T, S) if(is(S : T))
{
enum isSuperType = is(S : T);
}
static assert(is(SomeStruct : SomeInterface));
static assert(isSuperType!(SomeInterface, SomeStruct));
void main(){}
´´´
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
wrote:
> [...]
> so that a straight C++ namespace => D module hierarchy mapping
> would probably be required in the general case:
>
> ```
> // cppns/package.d
> module cppns;
> extern(C++, "cppns") { void foo(); }
>
> // cppns/nested/package.d
> module cppns.nested;
> extern(C++, "cppns") extern(C++, "nested") { void foo(); }
> ```
It's beautiful!
(but I added the quotes in there for you; without quotes is existing
defined behaviour which introduces scopes)
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sun, 29 Jul 2018 at 04:04, Jonathan M Davis via Digitalmars-d
wrote:
>
> On Sunday, July 29, 2018 2:28:08 AM MDT Walter Bright via Digitalmars-d
> wrote:
> > On 7/29/2018 1:15 AM, Manu wrote:
> > > All we're asking for is that C++ namespaces do **nothing** except affect
> > > the mangling.
> >
> > If I do that, the next bug report will be:
> >
> >extern (C++, "ab") { void foo(); }
> >extern (C++, "cd") { void foo(); } // Error, foo() is already declared
> >
> >foo(); // which one gets called?
> >
> > The reason namespaces were added to C++ is to not have such name
> > collisions. Namespaces in C++ introduce a scope. D cannot interoperate
> > with this without introducing a scope as well.
>
> I guess that the argument at that point is that you would have to put them
> in separate D modules, just like you would if they were extern(D) functions.
Or extern(C), or extern(C++), or extern(ObjectiveC)...
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sun, 29 Jul 2018 at 01:30, Walter Bright via Digitalmars-d
wrote:
>
> On 7/29/2018 1:15 AM, Manu wrote:
> > All we're asking for is that C++ namespaces do **nothing** except affect the
> > mangling.
>
> If I do that, the next bug report will be:
>
>extern (C++, "ab") { void foo(); }
>extern (C++, "cd") { void foo(); } // Error, foo() is already declared
>
>foo(); // which one gets called?
>
> The reason namespaces were added to C++ is to not have such name collisions.
> Namespaces in C++ introduce a scope. D cannot interoperate with this without
> introducing a scope as well.
You're really reaching here. Of course, this error is legitimate and correct.
Any D programmer knows they can't do this, and why would they expect they could?
There's no way you'll get a bug report from someone complaining they
can't multiply define symbols in the same scope. That's common sense.
They will intuitively move the second declaration into a second module.
...or they'll use your existing mechanism; it's in there now, we can't
remove it.
But please support a variant where we can specify namespace as a
string and opt-out of any funny business with scoping.
[Issue 19127] UDAs seem to be raw AST nodes rather than expressions
https://issues.dlang.org/show_bug.cgi?id=19127
--- Comment #1 from | ---
Other things you can use as UDAs:
* modules: @(std.stdio)
* packages: @(std)
* references to members: struct A { int i; } @(A.i)
* uint s; @(s++). This UDA changes every time you access it.
* @(new Object). Likewise.
* string str; @(str ~= "x"). Likewise.
The only thing that doesn't work is declarations, because that's forbidden by
the grammar. It seems like there's no special semantic analysis applied other
than recursing into child expressions.
Lowering should help:
@Something int x;
into
immutable __tmp = Something;
@__tmp int x;
--
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: This a thread to explore whether it would be feasible to do so. [...] What do you think? -- - Has the dmd/druntime split being annoying you too? I'm not familiar with contributing to the dmd/druntime, but having druntime in a separate repository never made sense to me. If it makes it easier for people to work on dmd/druntime, I'm all up for that. - Do you have a better suggestion? Not at all. - Would this break your workflow in a drastic way? Nope, in my workflow I either use dmd packages from pacman/apt or install.sh script. If these get updated on time I won't even notice that change.
[Issue 19127] UDAs seem to be raw AST nodes rather than expressions
https://issues.dlang.org/show_bug.cgi?id=19127 Seb changed: What|Removed |Added CC||greensunn...@gmail.com Hardware|x86_64 |All OS|Linux |All --
Re: stri: string format/interpolation library for D. how to embed variables into string like shell scripts
On Sunday, 29 July 2018 at 14:55:46 UTC, Shigeki Karita wrote:
This library is very similar to Scala or shell scripts.
- https://github.com/ShigekiKarita/stri/tree/master
-
https://docs.scala-lang.org/overviews/core/string-interpolation.html
## example
import stri : s;
// runtime/compile-time variables
auto a = 1;
enum _a0 = "D-lang";
struct A {
static a = 0.123;
}
// you can use the default %s and custom ones e.g., %.3f
mixin s!"${a} is one. ${_a0} is nice. ${A.a%.3f}" i;
assert(i.str == "1 is one. D-lang is nice. 0.123");
Seems fairly similar to `interp` in scriptlike:
https://github.com/Abscissa/scriptlike
BTW it wouldn't be so hard to add string interpolation to the
language and compiler, there have been two PRs now. This was the
latest:
https://github.com/dlang/dmd/pull/7988
I think someone just needs to take a bit of time and write a DIP,
so that A can't say no ;-)
[Issue 19127] UDAs seem to be raw AST nodes rather than expressions
https://issues.dlang.org/show_bug.cgi?id=19127 | changed: What|Removed |Added Keywords||accepts-invalid, spec --
[Issue 19127] New: UDAs seem to be raw AST nodes rather than expressions
https://issues.dlang.org/show_bug.cgi?id=19127
Issue ID: 19127
Summary: UDAs seem to be raw AST nodes rather than expressions
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dhase...@gmail.com
I've identified two issues related to this problem.
https://dlang.org/spec/attribute.html#uda says:
"User-Defined Attributes (UDA) are compile-time expressions that can be
attached to a declaration."
This should be invalid:
struct jsonize { string name; }
@jsonize int i;
`jsonize` is a type, but it is used as an expression. We see how this
misbehaves when we inspect it:
foreach (uda; __traits(getAttributes, i)) writeln(uda);
// Error: cannot pass type jsonize as a function argument
This is an issue whenever we try to inspect the content of a UDA that does not
have required parameters.
While looking for a workaround, I thought to create a function that returned
the UDA value, thinking this function would be executed at compile-time and the
result returned as a UDA value. This was not the case:
size_t print(string s = "hello world")
{
writeln(s);
return s.length;
}
@print int i;
void main()
{
writeln("testing");
static foreach (uda; __traits(getAttributes, j))
{
writeln(uda);
}
}
It compiles and prints:
testing
hello world
10
That shouldn't happen. The spec says the expression should be a compile-time
expression.
We see more clearly what's happening with pragma(msg):
struct _UDA2 {}
_UDA2 UDA2(string s) { writeln("hello world"); return _UDA2(); }
@UDA2("hi") int ir;
pragma(msg, __traits(getAttributes, ir).stringof);
This prints out: tuple(UDA2("hi")) -- it's a tuple containing a function call.
I suspect that this will produce strange breakages in rare cases when using
attributes at compile time (in addition to the current situation where invalid
code is accepted).
--
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 11:25:37 UTC, Mike Franklin wrote: On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: - Do you have a better suggestion? Do we have a rich enough CI API to recognize dependencies between repositories? For example, if I create a local branch in my dmd repository named `fix_bug` and a local branch in my druntime repository also named `fix_bug` and submit both PRs to their corresponding repositories, can the CI scripts recognize that they have the same branch name and pull them both for testing? Mike It's already implemented for branches under the respective dlang repository. This roughly happens on every CI: ```sh for proj in druntime phobos; do if [ $BRANCH != master ] && [ $BRANCH != stable ] && ! git ls-remote --exit-code --heads https://github.com/dlang/$proj.git $BRANCH > /dev/null; then # use master as fallback for other repos to test feature branches clone https://github.com/dlang/$proj.git ../$proj master else clone https://github.com/dlang/$proj.git ../$proj $BRANCH fi done ``` However, this only applies if the PR is targeting the respective branch, which means the workflow is a bit more annoying * push dmd branch to dlang/druntime-dmd * open PR at dmd targeting master (from druntime-dmd) * create druntime-dmd branch at dlang/druntime * push changes to private branch * open PR at druntime targetting druntime-dmd * merge druntime-dmd back to master once the druntime PR has been approved and merged It's a bit of an overhead for small changes though :/ Checking out the branch from your repository is problematic, because it's not exposed as environment variable and we would need to query the GitHub API to find this. Now the GitHub API gets rate-limited pretty quick, we would have to use our own GitHub API cache layer and ensure the requests coming from the CIs are really ours.
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
Eg turn this into a function and try wrapping this instead:
auto intp = interpreter(dmdEngine());
Actually, I manage to export the `interpret` method
export:
auto intp(char[] txt) {
return interpreter(dmdEngine()).interpret(txt);
}
and tested it in ipython successfully.
But when I try to export the whole dmdEngine
export:
auto engine(char[] txt) {
return interpreter(dmdEngine());
}
it complains about copying Interpreter!(DMDEngine).Interpreter
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/make_object.d(249,30):
Error: struct drepl.interpreter.Interpreter!(DMDEngine).Interpreter is not
copyable because it is annotated with @disable
I removed @disable, but then complained about accessing the
members `_engine` and `_incomplete` in Interpreter
(https://github.com/dlang-community/drepl/blob/master/src/drepl/interpreter.d#L147-L148)
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/struct_wrap.d-mixin-56(56,15):
Deprecation: std.array.Appender!(char[]).Appender._data is not visible from
module
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/struct_wrap.d-mixin-56(56,15):
Error: struct std.array.Appender!(char[]).Appender member _data is not
accessible
After I made those public, it complained about `Appender`
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/struct_wrap.d-mixin-56(56,15):
Deprecation: std.array.Appender!(char[]).Appender._data is not visible from
module
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/struct_wrap.d-mixin-56(56,15):
Error: struct std.array.Appender!(char[]).Appender member _data is not
accessible
Is there something I can do here or would it better to talk to
the Drepl guys?
Thank you
Re: How to get an inout constructor working with a template wrapper
On Sunday, 29 July 2018 at 12:45:48 UTC, Steven Schveighoffer wrote: Am I applying inout incorrectly? No, you need to apply it to wrap as well. I can't get run.dlang.io to work for posting a link, so here is my modified version: Ah bugger, right! Ok so there's no way to make explicit instantiation involving immutable work in the face of an inout parameter? Seems rather inconsistent no? https://issues.dlang.org/show_bug.cgi?id=19126 Thanks, - Ali
[Issue 19126] New: Compiler removes inout on templated parameter and then complains it's not there
https://issues.dlang.org/show_bug.cgi?id=19126
Issue ID: 19126
Summary: Compiler removes inout on templated parameter and then
complains it's not there
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ali.akhtarz...@gmail.com
struct W(T) {
this(U : T)(auto ref inout(U) val) inout {}
}
auto wrap0(T)(auto ref inout(T) t) {
return inout W!T();
}
auto wrap1(T)(auto ref inout(T) t) {
return t;
}
void main() {
wrap0!int(3); // ok
wrap0!(const int)(3); // ok
wrap0!(immutable int)(3); // Error: inout on return means inout must be on
a parameter
wrap1!int(3); // ok
wrap1!(const int)(3); // ok
wrap1!(immutable int)(3); // ok
}
--
Re: @betterC, @TestBetterC , @betterCTest or @("betterC") to annotate Phobos's unittests?
On Sunday, 29 July 2018 at 14:21:20 UTC, Seb wrote: Phobos has recently gotten a primitive way to run betterC tests (https://github.com/dlang/phobos/pull/6640). Now, it would be really cool if we can annotate existing tests with e.g. `@betterCTest` and thus ensure that those tests work with -betterC (i.e. extract them and run them with a minimal test runner. I don't really care as long is it contains the text "betterC" to ensure it's obvious at a glance what it's for. Does in need to be in the global namespace, or will it be in a private import? At some point we might also want to test whether something runs even without any runtime (https://github.com/dlang/phobos/pull/6641), so e.g. `@baremetalTest` might be defined too. I suggest the term "freestanding" over "baremetal", though, if it still requires the C standard library, it's not really freestanding, so hopefully this means without the druntime and without *any* other dependencies. Mike
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, July 29, 2018 6:10:01 AM MDT kinke via Digitalmars-d wrote:
> On Sunday, 29 July 2018 at 11:03:43 UTC, Jonathan M Davis wrote:
> > I guess that the argument at that point is that you would have
> > to put them in separate D modules, just like you would if they
> > were extern(D) functions.
>
> Yep, that'd sound acceptable to me, implying that
>
> ```
> extern(C++, cppns) { void foo(); }
> void foo();
> ```
>
> wouldn't work anymore, and particularly, this neither:
>
> ```
> extern(C++, cppns)
> {
> extern(C++, nested) { void foo(); }
> void foo();
> }
> ```
>
> so that a straight C++ namespace => D module hierarchy mapping
> would probably be required in the general case:
>
> ```
> // cppns/package.d
> module cppns;
> extern(C++, cppns) { void foo(); }
>
> // cppns/nested/package.d
> module cppns.nested;
> extern(C++, cppns) extern(C++, nested) { void foo(); }
> ```
Honestly, I'd expecting folks doing bindings for anything serious would be
matching the layout of the C++ header files being translated. It becomes
difficult to maintain bindings when their layout doesn't match the original
files. Most of druntime's C bindings match the layout of the C headers that
they're translating so that it's straightforward to find them (the primary
exception being that OS-specific symbols from a standard header end up in a
different file, which can be confusing and maybe shouldn't have been done,
but those files follow the same layout - just in a different hierarchy under
the OS's name). Anyone who didn't at least nominally make the layouts match
would almost certainly run into maintenance problems in the long run.
- Jonathan M Davis
Question about template argument matching with alias this
I have a question about template argument matching in combination
with implicit conversion and alias this. Consider the following
code:
interface SomeInterface
{
}
class SomeClass : SomeInterface
{
}
struct SomeStruct
{
SomeClass someClass;
alias someClass this;
}
template isSuperType(T, S : T)
{
enum isSuperType = is(SomeStruct : SomeInterface);
}
void main()
{
static assert(is(SomeStruct : SomeInterface));
static assert(isSuperType!(SomeInterface, SomeStruct)); //
why does the template not match?
}
The question is, why does the template declaration not match?
Thanks for your help!
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
Ok, I made a stupid mistake. It works now. Thanks a lot!
stri: string format/interpolation library for D. how to embed variables into string like shell scripts
This library is very similar to Scala or shell scripts.
- https://github.com/ShigekiKarita/stri/tree/master
-
https://docs.scala-lang.org/overviews/core/string-interpolation.html
## example
import stri : s;
// runtime/compile-time variables
auto a = 1;
enum _a0 = "D-lang";
struct A {
static a = 0.123;
}
// you can use the default %s and custom ones e.g., %.3f
mixin s!"${a} is one. ${_a0} is nice. ${A.a%.3f}" i;
assert(i.str == "1 is one. D-lang is nice. 0.123");
Re: Trailing comma in variable declaration
On Sunday, 29 July 2018 at 05:32:15 UTC, Ky-Anh Huynh wrote: Hi, is it nice to have a trailing comma in variable declaration: [code] bool verbose = false, download_only = false, no_confirm = false, show_help = false, show_version = false, list_ops = false, ; [/code] As trailing comma is possible (and it's great) for arrays, enum,... I wonder why we don't have this fancy thing for variables declaration. Thanks for your reading. This is the syntax sometimes seen with language that don't have trailling comma at all. bool verbose = false , download_only = false , no_confirm = false , show_help = false , show_version = false , list_ops = false ;
Re: @betterC, @TestBetterC , @betterCTest or @("betterC") to annotate Phobos's unittests?
On 30/07/2018 2:21 AM, Seb wrote: My favorite is (c) - any objections? As long as its a enum/struct and is documented some place with DDOC, then none here :)
@betterC, @TestBetterC , @betterCTest or @("betterC") to annotate Phobos's unittests?
Phobos has recently gotten a primitive way to run betterC tests
(https://github.com/dlang/phobos/pull/6640).
Now, it would be really cool if we can annotate existing tests
with e.g. `@betterCTest` and thus ensure that those tests work
with -betterC (i.e. extract them and run them with a minimal test
runner.
a) @betterC
Probably too popular and would lead to too many conflicts.
b) @TestBetterC
c) @betterCTest || @bettercTest
Would probably be defined a enum somewhere in `std.internal`
d) @("betterC")
A bit ugly and harder to work with. If we ever want to name the
unittests in Phobos, this will make it harder.
At some point we might also want to test whether something runs
even without any runtime
(https://github.com/dlang/phobos/pull/6641), so e.g.
`@baremetalTest` might be defined too.
My favorite is (c) - any objections?
See also: https://github.com/dlang/tools/pull/357 (implementation
of the test extraction filter for UDAs)
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 29 July 2018 at 08:28:08 UTC, Walter Bright wrote:
On 7/29/2018 1:15 AM, Manu wrote:
All we're asking for is that C++ namespaces do **nothing**
except affect the mangling.
If I do that, the next bug report will be:
extern (C++, "ab") { void foo(); }
extern (C++, "cd") { void foo(); } // Error, foo() is already
declared
foo(); // which one gets called?
The reason namespaces were added to C++ is to not have such
name collisions. Namespaces in C++ introduce a scope. D cannot
interoperate with this without introducing a scope as well.
Wouldn't something like this would prevent that :
extern (C++, "ab") { void foo(); }
extern (C++, "cd", "s") { void foo(); } // s is an optional D
scope
foo(); // works
s.foo(); // works too
Of course, it will imply some syntax change on the extern
keyword, as a new optional parameter will be added.
Re: How to avoid inout type constructor with Optional type wrapper undoing string type
On Sunday, 29 July 2018 at 12:30:58 UTC, Steven Schveighoffer wrote: On 7/28/18 6:06 PM, aliak wrote: [...] What I meant was that string is actually mutable (the data isn't mutable, but the string can be re-assigned to another one), so Optional!string is more useful than immutable(Optional!(char[])). I shouldn't have said that immutable(Optional!T) is useless, you are right, and it wouldn't make sense for the defined flag to change there anyway. [...] Ah right. So it seems inout is removing head qualifiers on by-val parameters? Filed what I think I understood from this: https://issues.dlang.org/show_bug.cgi?id=19125
[Issue 19125] New: IFTI and inout removes head mutability qualifier on by-val parameters
https://issues.dlang.org/show_bug.cgi?id=19125
Issue ID: 19125
Summary: IFTI and inout removes head mutability qualifier on
by-val parameters
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ali.akhtarz...@gmail.com
>From here: https://forum.dlang.org/post/jxcohrtxsfkechfgw...@forum.dlang.org
import std.stdio;
struct W(T) {
T t;
}
auto wrap0(T)(auto ref inout(T) t) {
return inout(W!T)(t);
}
auto wrap1(T)(auto ref inout(T) t) {
return t;
}
void main() {
pragma(msg, typeof(wrap0("foo"))); // removes it
pragma(msg, typeof(wrap1("bar"))); // keeps it
immutable int i0;
pragma(msg, typeof(wrap1(i0))); // keeps it
string s0 = "baz";
pragma(msg, typeof(wrap0(s0))); // keeps it
}
prints:
immutable(W!(char[]))
immutable(string)
immutable(int)
W!string
--
Re: How to get an inout constructor working with a template wrapper
On 7/28/18 6:09 PM, aliak wrote:
On Friday, 27 July 2018 at 14:38:27 UTC, Steven Schveighoffer wrote:
On 7/27/18 9:29 AM, aliak wrote:
Ok, thanks to Simen from another post [0], I just figured out what
the correct constructor and factory method for a template wrapper
should be:
https://run.dlang.io/is/S4vHzL
struct W(T) {
T val;
this(U : T, this This)(auto ref U val) {
this.val = val;
}
}
auto wrap(T)(auto ref T t) {
return W!T(t);
}
Seems to catch all cases!
And instantiate a new template for all mutabilities. Whereas inout
would only instantiate one (and disallows modification of val if not
const or immutable).
-Steve
If you change the ctor to be inout then you get (from the link above):
onlineapp.d(4): Error: cannot implicitly convert expression val of type
onlineapp.C to inout(C)
onlineapp.d(28): Error: template instance `onlineapp.W!(C).W.__ctor!(C)`
error instantiating
onlineapp.d(4): Error: cannot implicitly convert expression val of type
S1 to inout(S1)
onlineapp.d(44): Error: template instance
`onlineapp.W!(S1).W.__ctor!(S1)` error instantiating
onlineapp.d(4): Error: cannot implicitly convert expression val of type
onlineapp.C to inout(C)
onlineapp.d(9): Error: template instance `onlineapp.W!(C).W.__ctor!(C)`
error instantiating
onlineapp.d(52): instantiated from here: wrap!(C)
onlineapp.d(4): Error: cannot implicitly convert expression val of type
const(C) to inout(const(C))
onlineapp.d(9): Error: template instance
`onlineapp.W!(const(C)).W.__ctor!(const(C))` error instantiating
onlineapp.d(53): instantiated from here: wrap!(const(C))
Am I applying inout incorrectly?
No, you need to apply it to wrap as well. I can't get run.dlang.io to
work for posting a link, so here is my modified version:
struct W(T) {
T val;
this(U : T)(auto ref inout(U) val) inout {
this.val = val;
}
}
auto wrap(T)(auto ref inout(T) t) {
return inout W!T(t);
}
class C {}
struct S0 {}
struct S1 { C c; }
void f_dprimitive() {
int a = 3;
const int b = 3;
immutable int c = 3;
const int d = a;
immutable int e = a;
auto sc = wrap(const(int)(3)); // note the modifications here
auto si = wrap(immutable(int)(3));
}
void f_class() {
W!C a = new C();
const W!C b = new C();
immutable W!C c = new immutable C();
const W!C d = a;
//immutable W!C e = a; // cannot implicitly convert mutable to
immutable
}
void f_struct() {
W!S0 a = S0();
const W!S0 b = S0();
immutable W!S0 c = S0();
const W!S0 d = a;
immutable W!S0 e = a;
}
void f_struct_with_indirection() {
W!S1 a = S1();
const W!S1 b = S1();
immutable W!S1 c = immutable S1();
const W!S1 d = a;
//immutable W!S1 e = a; // cannot implicitly convert mutable to
immutable
}
void f_wrapper() {
auto a = wrap(new C);
auto b = wrap(new const C);
auto c = wrap(new immutable C);
const W!C d = a;
//immutable W!C e = a; // cannot implicitly convert mutable to immutable
}
void f_wrapper2() {
Object ma = new C();
Object ca = new const C();
Object ia = new immutable C();
auto a = wrap(cast(C)ma);
auto b = wrap(cast(const C)ma);
auto c = wrap(cast(immutable C)ma);
}
void main() {
}
Re: How to avoid inout type constructor with Optional type wrapper undoing string type
On 7/28/18 6:06 PM, aliak wrote:
On Friday, 27 July 2018 at 14:52:20 UTC, Steven Schveighoffer wrote:
On 7/23/18 2:39 PM, aliak wrote:
Hi,
I'm playing around with an Optional wrapper type. It stores a type T
and a bool that defines whether a value is defined or not:
struct Optional(T) {
T value;
bool defined = false;
this(U : T)(auto ref inout(U) value) inout {
this.value = value;
this.defined = true;
}
}
Don't use inout here. The point of inout on the constructor is to
*transfer* the mutability of the parameter to the struct instance. But
you want to simply copy the type into the struct (an
immutable(Optional!T) is quite useless, no?)
Just use U, not inout(U), and don't put inout on the constructor.
But then it only works for mutable Optional right? Why would an
immutable(Optional!T) be useless? Data can be "forever" empty or a
certain value.
What I meant was that string is actually mutable (the data isn't
mutable, but the string can be re-assigned to another one), so
Optional!string is more useful than immutable(Optional!(char[])). I
shouldn't have said that immutable(Optional!T) is useless, you are
right, and it wouldn't make sense for the defined flag to change there
anyway.
But I see a problem here. string *is* mutable, yet, the parameter is
accepted as inout(char[]). This seems unreasonable, I may want to
preserve the head mutability. I didn't realize IFTI would do this. May
be a bug, but I'm not certain.
But you have it as auto ref, which means since you only sent in rvalues
of strings, you didn't test the ref-ness of it. Indeed, if you do:
string s = "hello";
auto a = defined(s);
you get what you expected!
This doesn't make a whole lot of sense. I wouldn't expect different
types using IFTI this way. I'd recommend filing a bug on inout and IFTI.
There isn't a good way around this...
-Steve
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 29 July 2018 at 11:03:43 UTC, Jonathan M Davis wrote:
I guess that the argument at that point is that you would have
to put them in separate D modules, just like you would if they
were extern(D) functions.
Yep, that'd sound acceptable to me, implying that
```
extern(C++, cppns) { void foo(); }
void foo();
```
wouldn't work anymore, and particularly, this neither:
```
extern(C++, cppns)
{
extern(C++, nested) { void foo(); }
void foo();
}
```
so that a straight C++ namespace => D module hierarchy mapping
would probably be required in the general case:
```
// cppns/package.d
module cppns;
extern(C++, cppns) { void foo(); }
// cppns/nested/package.d
module cppns.nested;
extern(C++, cppns) extern(C++, nested) { void foo(); }
```
Re: std.getopt: Unexpected behavior when using incremental options
On Sunday, 29 July 2018 at 10:57:06 UTC, Cym13 wrote: On Sunday, 29 July 2018 at 09:28:41 UTC, Ky-Anh Huynh wrote: Hi, I am using std.getopt and expect to parse an incremental option with different names: --long, --longer, -l. The sample code is here [...] I think -long is actually taken as -l -o -n -g here. Since you didn't define -o, -n and -g it prints a usage error. I think that I've got that. There isn't any actual definition of short/long option names. That means if I provide [code] "l|long|longer+", _long [/code] getopt will define 6 variants: -l, --l, -long, --long, -longer, --longer, and here `-long`, `-l` and `-longer` are both short:) `Short` isn't related to the length of the option name. It's short because there is only one dash (-). This way using "short" is quite confusing. Regarding the output of the default help message, I should put `l` at the first position, as in `l|long|longer`. This is slightly different from examples in the official documentation (https://dlang.org/phobos/std_getopt.html) where you are expected to see `long|longer|l+` instead.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, July 29, 2018 2:28:08 AM MDT Walter Bright via Digitalmars-d
wrote:
> On 7/29/2018 1:15 AM, Manu wrote:
> > All we're asking for is that C++ namespaces do **nothing** except affect
> > the mangling.
>
> If I do that, the next bug report will be:
>
>extern (C++, "ab") { void foo(); }
>extern (C++, "cd") { void foo(); } // Error, foo() is already declared
>
>foo(); // which one gets called?
>
> The reason namespaces were added to C++ is to not have such name
> collisions. Namespaces in C++ introduce a scope. D cannot interoperate
> with this without introducing a scope as well.
I guess that the argument at that point is that you would have to put them
in separate D modules, just like you would if they were extern(D) functions.
If that were the only problem, then that doesn't sound like a big one -
especially if the documentation made it very clear that extern(C++)
declarations did not affect the lookup rules, thus forcing you to rely on
D's module system to deal with it all. All the extern(C++, NS) stuff does at
that point is to enable linking with C++ and forces all of the normal D
rules, which at least _sounds_ like it would be straightforward. If
anything, it seems like it would make things much simpler.
However, I've done nothing with C++ namespaces in D thus far. So, I really
can't comment on the problems beyond what I've read in threads like this
one.
- Jonathan M Davis
Re: std.getopt: Unexpected behavior when using incremental options
On Sunday, 29 July 2018 at 09:28:41 UTC, Ky-Anh Huynh wrote: Hi, I am using std.getopt and expect to parse an incremental option with different names: --long, --longer, -l. The sample code is here [...] I think -long is actually taken as -l -o -n -g here. Since you didn't define -o, -n and -g it prints a usage error.
Re: Trailing comma in variable declaration
On Saturday, July 28, 2018 11:32:15 PM MDT Ky-Anh Huynh via Digitalmars-d wrote: > Hi, > > is it nice to have a trailing comma in variable declaration: > > [code] >bool > verbose = false, > download_only = false, > no_confirm = false, > show_help = false, > show_version = false, > list_ops = false, > ; > [/code] > > As trailing comma is possible (and it's great) for arrays, > enum,... I wonder why we don't have this fancy thing for > variables declaration. > > Thanks for your reading. Well, most folks would just make those separate statements, in which case, there would be no commas at all. Some folks do put multiple variable declarations on a single line, but if you do that, a trailing comma looks terrible. I doubt that using a single statement to declare multiple variables but putting it on multiple lines was even a use case that was really considered. Also, a quick test with a C++ compiler shows that it's not legal there, so the rules we have with regard to this probably just came from C++. AFAIK, the only significant change that D has from C/C++ with regards to declaring multiple variables in a single statement is that the * is considered part of the type and thus int* a, b, c; declares three variables of type int* in D, whereas in C/C++, it would declare a single variable of type int* and two of type int. - Jonathan M Davis
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Saturday, 28 July 2018 at 14:45:19 UTC, Paolo Invernizzi wrote: I forgot the link... here it is: https://www.quantamagazine.org/to-make-sense-of-the-present-brains-may-predict-the-future-20180710 An interesting article. I found that Dennet's Consciousness Explained, which is presumably debunked old hat by now, is full of interesting experiments and speculation about how we model things in our mind and how our perceptions feed into that. It's a long time since I read it but if I remember correctly he shows how we seem to have a kind of mental theatre which has an expectation of what will come next from the senses, leading to interesting mistakes in perception. It's a useful model of how the mind works. That website often carries good articles about new maths as well. Me and my colleague are pretty different, in the approach to that kind of stuff... Maybe I'll post on the Forum a 'Request for D Advocacy', a-la PostgreSQL, so the community can try to address some of his concerns about modern D, and lower his discomfort! :-P If you can explain to me what is the _direction_ of D in terms of interfacing with large C++ libraries it would be very much appreciated! I'd love to be using D for some of my projects but I have a perception that using e.g. VTK is still a difficult thing to do from D. Is that still true? What is the long term plan for D, is it extern(C++), a binding technology? Is there any interest in Calypso from the upper echelons? I want to know where D is trying to go, not just where it is now. I want to know if anyone has got their heart in it. My CV says my main languages are Java, Python and D. That last one is mainly wishful thinking at the moment. I wish it wasn't! Make me believe, Paulo!
std.getopt: Unexpected behavior when using incremental options
Hi, I am using std.getopt and expect to parse an incremental option with different names: --long, --longer, -l. The sample code is here https://gist.github.com/icy/b8ed758b48134b369e854205aeb8f308 excerpt: [code] auto results = getopt(args, std.getopt.config.noBundling, std.getopt.config.passThrough, "longer|long|l+", _long ); [/code] I don't expect the program also accepts `-long` , unfortunately it does. The default help message also prints incorrect information: [code] $ rdmd tests.d -l -long --long --longer -h Basic usage: -long --longer -h --help This help information. How long it is: 4 Remained: "/tmp/.rdmd-314/rdmd-tests.d-0C7A52ECD8084516F3064EED864D6E86/tests" [/code] Did I have something wrong with my code? Thanks for your reading and support.
Re: On D in competitive programming
On Sunday, 29 July 2018 at 07:51:00 UTC, Jim Balter wrote: Actually, map!something does not drop empty parentheses, so mentioning that does not help. Parentheses containing 0 or 1 arguments can be omitted ... and you omit them for 1 argument in 3 places, and no instances of omitted empty parentheses. And I think it would be less confusing to an unfamiliar reader to mention UFCS, because the chained calls don't fit the function !(args1) (args2) syntax that you mention. While that's technically right, I'd like to skip further explanations of the syntax. The same as I skipped why the problem is solved by such code at all (and it's even less obvious). In both cases, careful explanations would require a good paragraph or two, but are beside the point. The point of the article is more to just show how it feels and to spark interest than to explain everything. On the other hand, if I had to write a guide for competitive programmers on how to use D, such things sure would be included. Ivan Kazmenko.
Re: On D in competitive programming
On Sunday, 29 July 2018 at 07:51:00 UTC, Jim Balter wrote: On Saturday, 28 July 2018 at 21:33:04 UTC, Ivan Kazmenko wrote: [snip] 2. When you briefly explain templates I think it's important to mention that empty parentheses may be omitted to allow the reader to make the link between function!(arg1)(arg2) and map!something. Explaining UFCS isn't necessary there though I think since it's obvious that there is some kind of chaining at play (not that you did, just thinking out loud). Yeah, good point, mentioned it now. Actually, map!something does not drop empty parentheses, so mentioning that does not help. Parentheses containing 0 or 1 arguments can be omitted ... and you omit them for 1 argument in 3 places, and no instances of omitted empty parentheses. And I think it would be less confusing to an unfamiliar reader to mention UFCS, because the chained calls don't fit the function !(args1) (args2) syntax that you mention. [snip] While it's certainly not exact I think it's fine, there's no need to rewrite the language specification. Even for the parentheses, once you know they may be dropped in unambiguous cases you are bound to assume that the author didn't start talking of the ! sign for no reason and that you ought to consider that parentheses may be dropped even not knowing all the reasons. The same goes for UFCS, it's made very clear by the article that the functions are chained. Whether they are actually functions, or function templates or methods or something else entirely isn't important. I think the reader can be expected to understand how it works without understanding why. They even know what the program does already so the chaining part isn't hard. Maybe I was wrong that it needed any addition after all. Or maybe the explaination of templates should be more streamlined toward what is in the code like “map here is a template, the ! sign is the equivalent of <> in C++" and no more.
Re: Is there any good reason why C++ namespaces are "closed" in D?
The name can be "transferred" into the global namespace using an alias. This boilerplate can all be put inside of a string mixin.
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 16:58:53 UTC, Greatsam4sure wrote: On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: [...] Every language is plague with one bug or the order. For those will great love for the language they lend a helping hand to fixed the bug. I expect you to help also in whatsoever capacity you can. What do you think pull requests are? I am just learning D but I am thoroughly satisfy with the language. For me it is truly joy. Goody for you, but how does that help?
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
On Tuesday, 10 July 2018 at 21:08:32 UTC, Cym13 wrote:
First of all I must point that I would very much like to have
seen a code actually producing an error in that article.
Contrary to what is hinted just taking the struct and putting
using it with Nullable or format() caused no error for me and
worked as expected.
To reproduce the format issue, try to print the struct with
writefln!"%s"(MyDomainType()).
To reproduce the Nullable issue, you need to slightly modify
the struct. In Phobos, Nullable will (due to an abundance of
caution) refuse to initialize the struct if the default
constructor is disabled; also you need a destructor. However,
for this it is enough to use any type that has a destructor, so
that an implicit struct destructor is generated. For verbosity,
I'll write it out:
struct MyDomainData {
string username;
this(string username) @safe
in(!username.empty) // only non-empty usernames please!
do { this.username = username; }
// let's formalise the restriction.
invariant { assert(!username.empty); }
string toString() { return null; }
~this() @safe { }
}
Then just stick it in a Nullable. No explicit .init needed.
That said, I may be missing something obvious but what
prevents you from overloading the init field?
struct MyDomainData {
string username;
@disable this(); // don't make a MyDomainData() by
accident!
this(string username)
in(!username.empty) // only non-empty usernames please!
do { this.username = username; }
// let's formalise the restriction.
invariant { assert(!username.empty); }
string toString() { ... }
static @property MyDomainData init() {
return MyDomainData("uninitialized");
}
...
}
auto test = MyDomainData.init; // There, no error
Of course that value means nothing but .init isn't meant to
actually mean something anyway, it's just a valid value and
that's what that init is proposing, so it shouldn't cause any
more bugs than empty .init in a normal case.
That would work, it's just a really horrible hack and I hate
it. We're constructing a fictitious domain value that passes
our invariants while having zero correspondence to the real
world, *just to pass our invariants*. It's an obvious sign of a
language issue.
If so, then the only language solution is to remove either
invariants or .init, because as long as .init can be called but
cannot be made to conform to your invariant, then your design is
beyond the scope of the language and you're in a pickle.
But the fact is that it's not a language issue and there are
several ways in user code to guarantee that .init satisfies the
invariant. In fact that very statement suggests a solution that
Timothy Cour suggested earlier:
invariant {
if(this is typeof(this).init) return;
assert(!username.empty);
}
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/29/2018 1:15 AM, Manu wrote:
All we're asking for is that C++ namespaces do **nothing** except affect the
mangling.
If I do that, the next bug report will be:
extern (C++, "ab") { void foo(); }
extern (C++, "cd") { void foo(); } // Error, foo() is already declared
foo(); // which one gets called?
The reason namespaces were added to C++ is to not have such name collisions.
Namespaces in C++ introduce a scope. D cannot interoperate with this without
introducing a scope as well.
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 16:54:18 UTC, Greatsam4sure wrote: On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: [...] Sincerely speaking D language does not merit all these criticism. The magnitude of criticism on D language does not really make sense to me. I am yet to see a language so user friendly as D with such power and strength.I trust one day the world will see and know that D is a language build for programmers for great productivity and not just another money making machine Yeah, D is great so let's not even have a bug database, eh?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sun., 29 Jul. 2018, 12:40 am Walter Bright via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On 7/28/2018 11:06 PM, Nicholas Wilson wrote: > > Then again I don't see any (non philosophical/compiler front end > internal) issue > > why you can't reopen a namespace. D is supposed to be pragmatic, after > all. > > Consider if a template reopens a namespace and throws a few more overloads > in > it. Then, what's in the namespace is dependent on which expansions are > done, in > which order. Throw in the inevitable circular references. Do people write > code > like that? Sure as shootin', they do, and they demand that it work, and > file > lots of bug reports about the erratic behavior. > > Next, consider a function body throwing a few more overloads in. Now, if > the > function body is compiled or not (and the compiler tries to avoid > compiling > bodies unless it has to) affects code that is outside of the function. > > C++ is full of stuff like that. The difference is, when code fails in some > bizarre way, programmers blame themselves and throw money at Scott Meyers > to > educate them on how to avoid writing such code. For D, they blame me. > > The last time we fixed scope lookup to make it more complicated was with > imports, and that took YEARS to sort out. > > So I'm a little reluctant to add features that will result in a rat's nest > of > problems I can neither explain nor fix, then someone will add 4000 > incomprehensible lines to fix 2 cases and add 5 or 6 bizarre regressions > in the > process and people complain the compiler is unstable. :-) > I don't understand your claims that it would somehow become problematic or incomprehensible. Are you saying D's module system is incomprehensible? All we're asking for is that C++ namespaces do **nothing** except affect the mangling. We want the D module system to work verbatim, without any new behaviours or edge cases of any kind. All symbols are normal symbols in their normal D module namespaces, and resolved according to all the normal name lookup rules... just the symbol mangling will make it link properly, just like extern(C) and extern(C++). You're insisting we accept this complex solution you cooked up with new scopes introduced which are not module scopes, and introduce practical problems for most that try and use it, and then somehow tell us that we're asking to complicate the language when we beg for normal D behaviour as an option... It doesn't make sense. We don't want to 'open' or 'reopen' a namespace. We just want to tell the function how to mangle right. Show me "4000 incomprehensible lines" that were introduced by the existence of extern(C) or extern(C++)? Because asking for a namespace as nothing more than a mangling attribute will have no further effect than any other extern statement; that's the point! >
Re: On D in competitive programming
On Saturday, 28 July 2018 at 21:33:04 UTC, Ivan Kazmenko wrote: [snip] 2. When you briefly explain templates I think it's important to mention that empty parentheses may be omitted to allow the reader to make the link between function!(arg1)(arg2) and map!something. Explaining UFCS isn't necessary there though I think since it's obvious that there is some kind of chaining at play (not that you did, just thinking out loud). Yeah, good point, mentioned it now. Actually, map!something does not drop empty parentheses, so mentioning that does not help. Parentheses containing 0 or 1 arguments can be omitted ... and you omit them for 1 argument in 3 places, and no instances of omitted empty parentheses. And I think it would be less confusing to an unfamiliar reader to mention UFCS, because the chained calls don't fit the function !(args1) (args2) syntax that you mention. [snip]
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/28/2018 9:23 PM, Manu wrote:
Don't troll me on this one, this is a very sensitive topic!
I could have a legit mental breakdown ;)
Here's another method:
--
extern (C++, ns) { int foo() { return 1; } }
mixin template X()
{
extern (C++, ns) { int bar() { return 2; } }
}
mixin X!() x;
---
and another:
-
extern (C++, ns) { int foo() { return 1; } }
struct S
{
extern (C++, ns) { int bar() { return 2; } }
}
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 7/28/2018 11:06 PM, Nicholas Wilson wrote: Then again I don't see any (non philosophical/compiler front end internal) issue why you can't reopen a namespace. D is supposed to be pragmatic, after all. Consider if a template reopens a namespace and throws a few more overloads in it. Then, what's in the namespace is dependent on which expansions are done, in which order. Throw in the inevitable circular references. Do people write code like that? Sure as shootin', they do, and they demand that it work, and file lots of bug reports about the erratic behavior. Next, consider a function body throwing a few more overloads in. Now, if the function body is compiled or not (and the compiler tries to avoid compiling bodies unless it has to) affects code that is outside of the function. C++ is full of stuff like that. The difference is, when code fails in some bizarre way, programmers blame themselves and throw money at Scott Meyers to educate them on how to avoid writing such code. For D, they blame me. The last time we fixed scope lookup to make it more complicated was with imports, and that took YEARS to sort out. So I'm a little reluctant to add features that will result in a rat's nest of problems I can neither explain nor fix, then someone will add 4000 incomprehensible lines to fix 2 cases and add 5 or 6 bizarre regressions in the process and people complain the compiler is unstable. :-)
Found D in the strangest of places... Right under the letter D
By some bizarre coincidence, or rightfully so, an (somewhat artificial attempt at a cleanroom-ish) unbiased attempt to find out what Google associates with each letter of the English alphabet, someone with extra time on their hands at BBC's technology department, I was pleasantly surprised to find, found D (language) to be the highest ranked single character Google search result for D, in good company, right next to the letter (and language) C. The article (link below) is titled "Google: An A to Z of search results" http://www.bbc.co.uk/news/technology-44725867 All I can think was—"D is going places" PS: Apologies for the excessive parentheticals. In an attempt to convey my precise thoughts, I might have murdered English Grammar and rendered the post incomprehensible. Although being humans—as opposed to an (NLP) bot—you should be able to get the point one way or the other. -- Sameer
Re: Request scoped information in Vibe.d
On Sunday, 22 July 2018 at 18:21:21 UTC, Venkat wrote:
On Sunday, 22 July 2018 at 08:43:23 UTC, Johannes Loher wrote:
On Sunday, 22 July 2018 at 06:21:40 UTC, Venkat wrote:
[...]
What is your usecase? If you simply want to pass a variable to
a diet template, just pass it as a template parameter to
render:
/* ... */
int myVar = 42;
render!("mytemplate.dt", myVar);
/* ... */
Then in mytemplate.dt, you can do something like:
p The best number ever is #{ myVar }
That is what I want to do. But what if I am redirecting the
user with some form errors ? In that case I am not using
render!.
Could you give a short example of what you are trying to do?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote: On 7/28/2018 11:18 AM, Manu wrote: Make a PR that implements namespace as a string... I will use that fork of D forever. 1. Look how it is mangled on the C++ side. (Use "grep" on the object file.) 2. Use: pragma(mangle, "the mangled name") People are trying to read C++ header files and convert the declarations ... how is that supposed to work? Even if they were manually adding declarations, this doesn't sound like a feasible approach.
[Issue 15373] Segfault when using typeid on extern(C++) class with virtual functions
https://issues.dlang.org/show_bug.cgi?id=15373 Mike Franklin changed: What|Removed |Added Keywords||pull CC||slavo5...@yahoo.com --- Comment #2 from Mike Franklin --- Attempted fix: https://github.com/dlang/dmd/pull/8526 --
ndslice v2 is coming soon
Hi, PR: https://github.com/libmir/mir-algorithm/pull/143 Features === * Slice and Series are C++ ABI compatible without additional wrappers. See example: https://github.com/libmir/mir-algorithm/tree/devel/cpp_example * Intuitive API with default params and without explicit dimension packs ``` alias Slice = mir_slice; struct mir_slice(Iterator, size_t N = 1, SliceKind kind = Contiguous) ``` For example, double[] analog is just Slice!(double*) / mir_slice. Best, Ilya Yaroshenko
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 29 July 2018 at 03:20:29 UTC, Walter Bright wrote: On 7/28/2018 11:18 AM, Manu wrote: Make a PR that implements namespace as a string... I will use that fork of D forever. 1. Look how it is mangled on the C++ side. (Use "grep" on the object file.) 2. Use: pragma(mangle, "the mangled name") That a) doesn't scale in a real dynamic codebase (think templates), and b) is platform dependent and so isn't a proper solution. Honestly the only problem with Manu's suggestion is you can't expose `a::foo` and `b::foo` with the same signature within the same module due to (D) name collisions, although I don't see any reason why we can't do both. Then again I don't see any (non philosophical/compiler front end internal) issue why you can't reopen a namespace. D is supposed to be pragmatic, after all.
