Re: How to list aggregate members in order of declaration at compile time?
On Friday, 11 November 2016 at 23:55:58 UTC, Jonathan M Davis wrote: ... So, just provide a solid use case (if not multiple) as to why it needs to have a specific order, and you probably stand a good chance of it being added to the spec - especially since it's what the implementation does anyway, and the implementation isn't likely to change. And given that tupleof simply gives the member variables, I don't know of a good argument for why it should ever do anything other than given them in the order that they're declared. - Jonathan M Davis Hello, here is an issue (with a use case): https://issues.dlang.org/show_bug.cgi?id=19036 Guillaume Lathoud
Re: Is there a way to get the address of the function that would be used in Implicit Function Template Instantiation?
On Wednesday, June 27, 2018 22:59:03 Nathan S. via Digitalmars-d-learn
wrote:
> On Wednesday, 27 June 2018 at 22:39:26 UTC, Jonathan M Davis
>
> wrote:
> > You could explicitly instantiate the function template and then
> > take its address.
>
> Explicitly instantiating the template can result in a function
> that may be behaviorally identical but have a different address.
>
> https://run.dlang.io/is/E9WroB
> ---
> auto foo(T)(const T x) { return x; }
>
> void main()
> {
> const int a;
> assert(!int !is !(const int)); // The addresses are
> different.
> foo(a); // If I look in the object file I can see this uses
> foo!int.
> assert(!(typeof(a)) !is !int);
> }
> ---
Well, instantiating a template with int is definitely going to give a
different funcion than instantiating with const int would, since they're
different instantiations. My guess as to why foo(a) gets inferred as foo!int
rather than foo!(const int) is because you made the parameter explicitly
const, so the compiler then decides that T is the type without const and
thus infers it to be int. Certainly, the surest thing to do is to explictly
instantiate the template and use the explicit instantiation when calling it.
I don't know if it's actually possible to even get the explicit instantation
that was used for foo(a), let alone get the address of the resulting
function. typeof(foo(a)) gives the type of the result, not the type of the
function.
- Jonathan M Davis
Re: Is there a way to get the address of the function that would be used in Implicit Function Template Instantiation?
On 6/27/18 6:34 PM, Nathan S. wrote: Let's say there's a function template `doImpl` and `doImpl(x)` compiles thanks to IFTI. Is there any way to get the address of the function that would be called in `doImpl(x)`? It's a good question! You may be able to use TemplateOf, TemplateArgsOf, and Instantiate to generate the actual instantiation. -Steve
Re: Is there a way to get the address of the function that would be used in Implicit Function Template Instantiation?
On Wednesday, 27 June 2018 at 22:39:26 UTC, Jonathan M Davis
wrote:
You could explicitly instantiate the function template and then
take its address.
Explicitly instantiating the template can result in a function
that may be behaviorally identical but have a different address.
https://run.dlang.io/is/E9WroB
---
auto foo(T)(const T x) { return x; }
void main()
{
const int a;
assert(!int !is !(const int)); // The addresses are
different.
foo(a); // If I look in the object file I can see this uses
foo!int.
assert(!(typeof(a)) !is !int);
}
---
Re: Is there a way to get the address of the function that would be used in Implicit Function Template Instantiation?
On Wednesday, June 27, 2018 22:34:46 Nathan S. via Digitalmars-d-learn wrote: > Let's say there's a function template `doImpl` and `doImpl(x)` > compiles thanks to IFTI. Is there any way to get the address of > the function that would be called in `doImpl(x)`? You could explicitly instantiate the function template and then take its address. - Jonathan M Davis
Is there a way to get the address of the function that would be used in Implicit Function Template Instantiation?
Let's say there's a function template `doImpl` and `doImpl(x)` compiles thanks to IFTI. Is there any way to get the address of the function that would be called in `doImpl(x)`?
Re: anyway to pass the context of an inner type to a template so it can be constructed?
On Wednesday, 27 June 2018 at 19:28:37 UTC, Timoses wrote: Can't seem to avoid using mixin in main.. hehe yeah I see, didn't think of trying mixins, worth a shot! It seems like you had fun at least ;)
Re: anyway to pass the context of an inner type to a template so it can be constructed?
On Wednesday, 27 June 2018 at 14:01:03 UTC, Alex wrote:
On Wednesday, 27 June 2018 at 12:02:10 UTC, aliak wrote:
===
The use case is for a non-nullable type, where I want to
guarantee that the value inside will never be null. I can't do
it for inner classes though. And I can't allow the user to do
something like:
void main() {
class C {}
auto s = construct(new C);
}
Because I can't guarantee that's not null.
Cheers,
- Ali
Is there any reason, why you don't want to use a struct? An
instance of such is never null, still having access to its
context, if it is a function.
Sorry, by non-nullable I meant not null. It's that construct
produces a wrapper type that has an internal value that I want to
guarantee is not null. So whether T is a struct or class is
dependent on the user of construct.
- Ali
Re: anyway to pass the context of an inner type to a template so it can be constructed?
On Wednesday, 27 June 2018 at 12:02:10 UTC, aliak wrote:
This currently fails unless you mark the class as static:
auto construct(T)() {
return new T;
}
void main() {
class C {}
auto s = construct!C;
}
So wondering if there's anything that can be done to get the
above working?
Or if there isn't then how could the compiler be enhanced to
allow for something like this if possible?
===
The use case is for a non-nullable type, where I want to
guarantee that the value inside will never be null. I can't do
it for inner classes though. And I can't allow the user to do
something like:
void main() {
class C {}
auto s = construct(new C);
}
Because I can't guarantee that's not null.
Cheers,
- Ali
After a bit of experimentation
import std.stdio;
template construct1(T)
{
enum construct1 = "new " ~ T.stringof;
}
template construct2(T)
{
// Attempt 1
// can't do this : /
//alias construct2 = mixin(construct1!T);
// Attempt 2
T construct2()
{
// Error: outer function context of D main is needed
to new nested class onlineapp.main.C
//return new T;
// Error: undefined identifier C
//mixin("return new " ~ T.stringof ~ ";");
return null; // ...
}
}
mixin template construct3(string s, T)
{
mixin("auto " ~ s ~ " = new " ~ T.stringof ~ ";");
}
void main() {
class C { int i = 4;}
auto a = mixin(construct1!C);
assert(a.i == 4);
mixin construct3!("b", C);
b.i = 3;
assert(b.i == 3);
// trying to get around using mixin here...
auto c = construct2!C;
}
Can't seem to avoid using mixin in main..
Re: Visual D 0.47.0 released
On 27/06/2018 12:37, Robert M. Münch wrote: On 2018-06-27 06:22:19 +, Rainer Schuetze said: - Windows-10, 64bit, running in a Parallels VM on OSX 10.13.5 - VS-2017 latest patch applied If you try to debug 64-bit-builds, mago starts another monitoring process. Maybe there are issues with this in the Parallels VM. Please note that there is no need to select the Mago debug engine in VS2013 or later. Since a couple of versions of Visual D, the VS debugger is equipped with an extension based on Mago that can evaluate D expressions. Ok, so maybe the problem is related to changing the selection via the drop-down box in the project properties. If I use "Visual Studio" things work. If I switch to "Mango" things don't work. WRT: D expressions. I saw that variables inside a foreach body, where an opApply is used, are not visible in the debugger. I get a "symbol not found" message. Not sure if this is bacause of the foreach body beging used as a delegate? Delegate literals are problematic if the variables are declared outside of delegate: dmd doesn't emit debug info for these. LDC is often better in that regard.
Re: Preferred Alias Declaration Style
On Wednesday, 27 June 2018 at 15:27:09 UTC, Steven Schveighoffer
wrote:
On 6/27/18 6:22 AM, Vijay Nayar wrote:
Does this mean that the `alias other aliasName;` syntax is
preferred, or does it simply mean that this is a low priority
issue that hasn't been addressed yet?
IIRC, there was an ambiguity for using the new syntax for alias
this. I don't remember the thread where it was discussed, but
you are not the first to bring it up.
-Steve
The ambiguity is that `this` resolves to a type in aggregates:
```
class Foo
{
alias FooToo = this;
static assert(is(FooToo == Foo));
}
```
Fortunately this is being removed from the language see:
https://github.com/dlang/dmd/commit/524a924477fa02bc2ff11de085f93ab657377d0a
Re: Struct template cannot deduce function from argument types
On Wednesday, 27 June 2018 at 17:07:52 UTC, Jonathan M Davis wrote: On Wednesday, June 27, 2018 16:19:56 Luka Aleksic via Digitalmars-d-learn wrote: [...] [...] Well, for one, what's on the left side of the = doesn't normally affect the type of what's on the right. It does in some cases with literals - e.g. [...] Thank you very much for a clear explanation and examples of how to do this sort of thing idiomatically. Very useful and cleared up all I was confused about.
Re: Struct template cannot deduce function from argument types
On Wednesday, 27 June 2018 at 16:19:56 UTC, Luka Aleksic wrote:
[…]
I am getting the following error:
scratch.d(14): Error: struct scratch.pair cannot deduce
function from argument types !()(char, int), candidates are:
scratch.d(2):scratch.pair(T, U)
Failed: ["/usr/bin/dmd", "-v", "-o-", "scratch.d", "-I."]
Changing the offending line to:
pair!(char, uint) p1 = pair!(char, uint)('a', 1);
fixes the issue.
However I am interested to know why the first code couldn't
deduce the types-- and why does it even have to try to deduce
them, when I explicitly stated that p1 was of the type "pair of
char and uint"?
Thanks,
L. Aleksic
Type inference does not work for struct construction. There are
some technical problems with allowing that, such as this() having
the capability of being a separate template itself.
Relevant issue tracker entry:
https://issues.dlang.org/show_bug.cgi?id=6082
Your construction call does not work because the right hand side
determines its type using only information present on the right
hand side, in that sense you're not explicitly providing types at
all.
In order to still be able to make concise construction calls, you
can define a factory function:
struct Pair(A, B)
{
A a;
B b;
this(A a, B b)
{
this.a = a;
this.b = b;
}
}
Pair!(A, B) pair(A, B)(A a, B b)
{
return Pair!(A, B)(a, b);
}
void main()
{
auto p = pair(1, "test");
pragma(msg, typeof(p)); //Pair!(int, string)
}
Re: Struct template cannot deduce function from argument types
On Wed, Jun 27, 2018 at 04:19:56PM +, Luka Aleksic via Digitalmars-d-learn
wrote:
[...]
> struct pair(T, U) {
> T first;
> U second;
>
> this(T arg_first, U arg_second) {
> first = arg_first;
> second = arg_second;
> }
> };
>
> void main() {
>
> pair!(char, uint) p1 = pair('a', 1);
The usual way I'd write this is:
auto p1 = pair!(char, uint)('a', 1);
This saves having to retype a complicated type, and also gives the
compiler the template arguments in the place where it needs them.
[...]
> I am getting the following error:
>
> scratch.d(14): Error: struct scratch.pair cannot deduce function from
> argument types !()(char, int), candidates are:
> scratch.d(2):scratch.pair(T, U)
> Failed: ["/usr/bin/dmd", "-v", "-o-", "scratch.d", "-I."]
The reason is that the compiler runs semantic on the right-hand side of
the assignment first, before it looks at the type of p1. The expression
`pair('a', 1)` is ambiguous, since the compiler doesn't (yet) know which
instantiation of `pair` you intended.
Writing it the way I recommend above avoids this problem.
T
--
Answer: Because it breaks the logical sequence of discussion.
Question: Why is top posting bad?
Re: Struct template cannot deduce function from argument types
On Wednesday, June 27, 2018 16:19:56 Luka Aleksic via Digitalmars-d-learn
wrote:
> Hello,
>
> In the following code:
>
> T first;
> U second;
>
> this(T arg_first, U arg_second) {
> first = arg_first;
> second = arg_second;
> }
> };
>
> void main() {
>
> pair!(char, uint) p1 = pair('a', 1);
>
> }
>
> I am getting the following error:
>
> scratch.d(14): Error: struct scratch.pair cannot deduce function
> from argument types !()(char, int), candidates are:
> scratch.d(2):scratch.pair(T, U)
> Failed: ["/usr/bin/dmd", "-v", "-o-", "scratch.d", "-I."]
>
> Changing the offending line to:
>
> pair!(char, uint) p1 = pair!(char, uint)('a', 1);
>
> fixes the issue.
>
> However I am interested to know why the first code couldn't
> deduce the types-- and why does it even have to try to deduce
> them, when I explicitly stated that p1 was of the type "pair of
> char and uint"?
>
> Thanks,
> L. Aleksic
Well, for one, what's on the left side of the = doesn't normally affect the
type of what's on the right. It does in some cases with literals - e.g.
char c = 'a';
compiles just fine in spite of the fact that 'a' is a dchar, but if what's
on the right-hand side is not a literal, then the type has to match or be
implicitly convertible to the type of the variable it's initializing or
being assigned to. And it's definitely not the case that any template
instantitaions on the right-hand side get instantiated based on what's on
the left. pair('a', 1) has to compile on its own and result in a type which
implicitly converts to pair!(char, uint) for your code to work, and that's
definitely not the case.
The other big issue here is that the only time that templates are ever
implicitly instantiated is for functions - which is why it's called IFTI
(implicit function template instantiation). Even something like
struct S(T = int)
{
}
S s;
would not compile, because S is a template. The code would have to use
S!() s;
or
S!int s;
S by itself is not a type. It's a template. This can be annoying at times,
but it stems from the fact that you'd get various ambiguities otherwise.
e.g. if S was implicitly instantiatied as S!int, then what would
alias Foo = S;
mean? It could be the template, or it could be the instantiation of the
template. Because of that, implicit instantation never happens for types.
So, when the compiler sees pair('a', 1), there is no function named pair.
There is no constructor. There isn't even a type named pair.
pair!(char, uint) would be a type, or it would be a constructor, but pair is
just a template. So, when it sees
pair!(char, uint) p1 = pair('a', 1);
it sees you trying to call a function that doesn't exist. There is no
function pair - not even a templated function named pair.
However, while there is ambiguity in implicitly instantiating templated
types, for functions, there is no ambiguity (since the function call syntax
is unambiguous). So, templated functions _can_ have their template arguments
infered (hence IFTI). So, the typical solution to this sort of problem is to
create a helper function. e.g.
struct Pair(T, U)
{
T first;
U second;
this(T arg_first, U arg_second)
{
first = arg_first;
second = arg_second;
}
}
auto pair(T, U)(T first, U second)
{
return Pair!(T, U)(first, second);
}
That way, you have a function which can take advantage of IFTI to infer the
template arguments (what you'd do for naming in your case if you want to use
camelCasing for types, I don't know, but normally, D code uses PascalCasing
for types and camelCasing for functions, which makes the naming pretty
straightforward in cases like this). Now, even then
Pair!(char, uint) p1 = pair('a', 1);
won't compile, because the literal 'a' defaults to dchar, and the literal 1,
defaults to int. So, pair('a', 1) would have the type Pair!(dchar, int). 1u
could be used to turn 1 into a uint literal, but you'd have to use a cast to
force 'a' to be a char. e.g.
Pair!(char, uint) p1 = pair(cast(char)'a', 1u);
Now, normally, you also wouldn't put the type on the left-hand side of a
variable declaration like that. You'd just use auto - e.g.
auto p1 = pair('a', 1);
but if you want that specific type, you'd need to do something like
auto p1 = pair(cast(char)'a', 1u);
or
auto p1 = pair!(char, uint)('a', 1);
though if you're doing that, you don't even need the helper function and
could just do
auto p1 = Pair!(char, uint)('a', 1);
The helper function does often help though, much as it's less helpful with
those particular literals given the type that you want.
In any case, I would point out that unless you're doing something beyond
what's typically for a pair or tuple type, there's no reason to declare a
Pair type like what you have here. std.typecons.Tuple already takes care of
that for you. So, Tuple!(char, uint) would declare basically the same type
that you were trying to use and tuple can be used to construct on - e.g.
auto p1 = tuple('a', 1);
or
auto p1 =
Struct template cannot deduce function from argument types
Hello,
In the following code:
struct pair(T, U) {
T first;
U second;
this(T arg_first, U arg_second) {
first = arg_first;
second = arg_second;
}
};
void main() {
pair!(char, uint) p1 = pair('a', 1);
}
I am getting the following error:
scratch.d(14): Error: struct scratch.pair cannot deduce function
from argument types !()(char, int), candidates are:
scratch.d(2):scratch.pair(T, U)
Failed: ["/usr/bin/dmd", "-v", "-o-", "scratch.d", "-I."]
Changing the offending line to:
pair!(char, uint) p1 = pair!(char, uint)('a', 1);
fixes the issue.
However I am interested to know why the first code couldn't
deduce the types-- and why does it even have to try to deduce
them, when I explicitly stated that p1 was of the type "pair of
char and uint"?
Thanks,
L. Aleksic
Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length
On Wednesday, 27 June 2018 at 15:18:05 UTC, Alex wrote: On Wednesday, 27 June 2018 at 15:07:57 UTC, Uknown wrote: On Wednesday, 27 June 2018 at 14:50:25 UTC, Alex wrote: On Wednesday, 27 June 2018 at 14:29:33 UTC, Uknown wrote: On Wednesday, 27 June 2018 at 14:21:39 UTC, Alex wrote: On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote: [...] This would: ["123".byCodeUnit.permutations].joiner.writeln; Thanks. This works, but it still seems silly that permutations doesn't just return a range with front returning the original type
Re: Preferred Alias Declaration Style
On 6/27/18 6:22 AM, Vijay Nayar wrote: Does this mean that the `alias other aliasName;` syntax is preferred, or does it simply mean that this is a low priority issue that hasn't been addressed yet? IIRC, there was an ambiguity for using the new syntax for alias this. I don't remember the thread where it was discussed, but you are not the first to bring it up. -Steve
Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length
On Wednesday, 27 June 2018 at 15:07:57 UTC, Uknown wrote: On Wednesday, 27 June 2018 at 14:50:25 UTC, Alex wrote: On Wednesday, 27 June 2018 at 14:29:33 UTC, Uknown wrote: On Wednesday, 27 June 2018 at 14:21:39 UTC, Alex wrote: On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote: [...] I see. Ok, one possibility is source = indexed(source, indices).array; but I assume you want something without extra allocation, right? This doesn't work for some reason. "123".byCodeUnit.permutations.array.writeln //[123, 123, 123, 123, 123, 123] This would: ["123".byCodeUnit.permutations].joiner.writeln;
Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length
On Wednesday, 27 June 2018 at 14:50:25 UTC, Alex wrote: On Wednesday, 27 June 2018 at 14:29:33 UTC, Uknown wrote: On Wednesday, 27 June 2018 at 14:21:39 UTC, Alex wrote: On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote: [...] I see. Ok, one possibility is source = indexed(source, indices).array; but I assume you want something without extra allocation, right? This doesn't work for some reason. "123".byCodeUnit.permutations.array.writeln //[123, 123, 123, 123, 123, 123]
Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length
On Wednesday, 27 June 2018 at 14:29:33 UTC, Uknown wrote: On Wednesday, 27 June 2018 at 14:21:39 UTC, Alex wrote: On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote: Title says it all. Is there a trivial way to do this? There are https://dlang.org/library/std/algorithm/mutation/reverse.html and https://dlang.org/library/std/range/retro.html both require a bidirectional range, which Indexed, luckily is. I wasn't clear enough. I meant getting back the underlying `Source` range with _its_ elements in the order that the indices specify. This wouldn't be possible in the generic case, but the special case when indices.length == source.length, it should be possible. So indexed(myRange, [2, 3, 5, 1, 4]).sourceWithSwappedElements should return a typeof(myRange) with the elements swapped in that order. I see. Ok, one possibility is source = indexed(source, indices).array; but I assume you want something without extra allocation, right?
Re: Preferred Alias Declaration Style
On Wednesday, 27 June 2018 at 14:29:18 UTC, Basile B. wrote:
On Wednesday, 27 June 2018 at 14:23:25 UTC, Uknown wrote:
On Wednesday, 27 June 2018 at 14:01:06 UTC, Basile B. wrote:
[...]
You can use this syntax for functions :
`alias proto_identifier = void function();`
Nah it's not the same thing ;)
void main()
{
alias void proto_identifier_old();
alias proto_identifier_new = void function();
assert(!is(proto_identifier_old == proto_identifier_new));
// passes
}
- proto_identifier_new is a function type (stuff)
- proto_identifier_new is a function **pointer** type (e.g
)
Actually my answer was more informative because i reported this
limitation years ago, see
https://issues.dlang.org/show_bug.cgi?id=16020.
Ah s**t i meant
- proto_identifier_old is a function type (stuff)
- proto_identifier_new is a function **pointer** type
Re: Preferred Alias Declaration Style
On Wednesday, 27 June 2018 at 14:29:18 UTC, Basile B. wrote:
On Wednesday, 27 June 2018 at 14:23:25 UTC, Uknown wrote:
On Wednesday, 27 June 2018 at 14:01:06 UTC, Basile B. wrote:
On Wednesday, 27 June 2018 at 12:25:26 UTC, Uknown wrote:
On Wednesday, 27 June 2018 at 10:22:38 UTC, Vijay Nayar
wrote:
[...]
Nah it's not the same thing ;)
void main()
{
alias void proto_identifier_old();
alias proto_identifier_new = void function();
assert(!is(proto_identifier_old == proto_identifier_new));
// passes
}
- proto_identifier_new is a function type (stuff)
- proto_identifier_new is a function **pointer** type (e.g
)
Actually my answer was more informative because i reported this
limitation years ago, see
https://issues.dlang.org/show_bug.cgi?id=16020.
Didn't know that, I assumed that the old style also declared a
function pointer
Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length
On Wednesday, 27 June 2018 at 14:21:39 UTC, Alex wrote: On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote: Title says it all. Is there a trivial way to do this? There are https://dlang.org/library/std/algorithm/mutation/reverse.html and https://dlang.org/library/std/range/retro.html both require a bidirectional range, which Indexed, luckily is. I wasn't clear enough. I meant getting back the underlying `Source` range with _its_ elements in the order that the indices specify. This wouldn't be possible in the generic case, but the special case when indices.length == source.length, it should be possible. So indexed(myRange, [2, 3, 5, 1, 4]).sourceWithSwappedElements should return a typeof(myRange) with the elements swapped in that order.
Re: Preferred Alias Declaration Style
On Wednesday, 27 June 2018 at 14:23:25 UTC, Uknown wrote:
On Wednesday, 27 June 2018 at 14:01:06 UTC, Basile B. wrote:
On Wednesday, 27 June 2018 at 12:25:26 UTC, Uknown wrote:
On Wednesday, 27 June 2018 at 10:22:38 UTC, Vijay Nayar wrote:
[...]
aliasing a function type only works with the old syntax too:
alias void proto_identifier();
Very unfriendly syntax. Impossible to express with
AliasDeclarationY (aka "the new alias syntax").
You can use this syntax for functions :
`alias proto_identifier = void function();`
Nah it's not the same thing ;)
void main()
{
alias void proto_identifier_old();
alias proto_identifier_new = void function();
assert(!is(proto_identifier_old == proto_identifier_new)); //
passes
}
- proto_identifier_new is a function type (stuff)
- proto_identifier_new is a function **pointer** type (e.g )
Actually my answer was more informative because i reported this
limitation years ago, see
https://issues.dlang.org/show_bug.cgi?id=16020.
Re: Preferred Alias Declaration Style
On Wednesday, 27 June 2018 at 14:01:06 UTC, Basile B. wrote: On Wednesday, 27 June 2018 at 12:25:26 UTC, Uknown wrote: On Wednesday, 27 June 2018 at 10:22:38 UTC, Vijay Nayar wrote: [...] aliasing a function type only works with the old syntax too: alias void proto_identifier(); Very unfriendly syntax. Impossible to express with AliasDeclarationY (aka "the new alias syntax"). You can use this syntax for functions : `alias proto_identifier = void function();`
Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length
On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote: Title says it all. Is there a trivial way to do this? There are https://dlang.org/library/std/algorithm/mutation/reverse.html and https://dlang.org/library/std/range/retro.html both require a bidirectional range, which Indexed, luckily is.
Re: anyway to pass the context of an inner type to a template so it can be constructed?
On Wednesday, 27 June 2018 at 12:02:10 UTC, aliak wrote:
===
The use case is for a non-nullable type, where I want to
guarantee that the value inside will never be null. I can't do
it for inner classes though. And I can't allow the user to do
something like:
void main() {
class C {}
auto s = construct(new C);
}
Because I can't guarantee that's not null.
Cheers,
- Ali
Is there any reason, why you don't want to use a struct? An
instance of such is never null, still having access to its
context, if it is a function.
Re: Preferred Alias Declaration Style
On Wednesday, 27 June 2018 at 12:25:26 UTC, Uknown wrote: On Wednesday, 27 June 2018 at 10:22:38 UTC, Vijay Nayar wrote: Most of the documentation at https://dlang.org/spec/declaration.html#alias uses examples of the form: `alias aliasName = other;`, where `aliasName` becomes the new name to reference `other`. Alternatively, one may write `alias other aliasName;`. My understanding is that the syntax with `=` is the preferred one stylistically. However, when it comes to `alias this` declarations, the only syntax supported is `alias other this;`, and one cannot write `alias this = other;`. Does this mean that the `alias other aliasName;` syntax is preferred, or does it simply mean that this is a low priority issue that hasn't been addressed yet? `alias Alias = SomeType;` is preferred. It is the new style, and is more clear on what is the alias and what is the new type, especially when complex types come into play. For `alias this` though, there is only one syntax, `alias other this;`, since it does something conceptually different from regular aliases. aliasing a function type only works with the old syntax too: alias void proto_identifier(); Very unfriendly syntax. Impossible to express with AliasDeclarationY (aka "the new alias syntax").
Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length
Title says it all. Is there a trivial way to do this?
Re: Preferred Alias Declaration Style
On Wednesday, 27 June 2018 at 10:22:38 UTC, Vijay Nayar wrote: Most of the documentation at https://dlang.org/spec/declaration.html#alias uses examples of the form: `alias aliasName = other;`, where `aliasName` becomes the new name to reference `other`. Alternatively, one may write `alias other aliasName;`. My understanding is that the syntax with `=` is the preferred one stylistically. However, when it comes to `alias this` declarations, the only syntax supported is `alias other this;`, and one cannot write `alias this = other;`. Does this mean that the `alias other aliasName;` syntax is preferred, or does it simply mean that this is a low priority issue that hasn't been addressed yet? `alias Alias = SomeType;` is preferred. It is the new style, and is more clear on what is the alias and what is the new type, especially when complex types come into play. For `alias this` though, there is only one syntax, `alias other this;`, since it does something conceptually different from regular aliases.
anyway to pass the context of an inner type to a template so it can be constructed?
This currently fails unless you mark the class as static:
auto construct(T)() {
return new T;
}
void main() {
class C {}
auto s = construct!C;
}
So wondering if there's anything that can be done to get the
above working?
Or if there isn't then how could the compiler be enhanced to
allow for something like this if possible?
===
The use case is for a non-nullable type, where I want to
guarantee that the value inside will never be null. I can't do it
for inner classes though. And I can't allow the user to do
something like:
void main() {
class C {}
auto s = construct(new C);
}
Because I can't guarantee that's not null.
Cheers,
- Ali
Re: Visual D 0.47.0 released
On 2018-06-27 06:22:19 +, Rainer Schuetze said: Works for me, can you give more details? VS version, platform, etc. - Windows-10, 64bit, running in a Parallels VM on OSX 10.13.5 - VS-2017 latest patch applied Please note that there is no need to select the Mago debug engine in VS2013 or later. Since a couple of versions of Visual D, the VS debugger is equipped with an extension based on Mago that can evaluate D expressions. Ok, so maybe the problem is related to changing the selection via the drop-down box in the project properties. If I use "Visual Studio" things work. If I switch to "Mango" things don't work. WRT: D expressions. I saw that variables inside a foreach body, where an opApply is used, are not visible in the debugger. I get a "symbol not found" message. Not sure if this is bacause of the foreach body beging used as a delegate? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Preferred Alias Declaration Style
Most of the documentation at https://dlang.org/spec/declaration.html#alias uses examples of the form: `alias aliasName = other;`, where `aliasName` becomes the new name to reference `other`. Alternatively, one may write `alias other aliasName;`. My understanding is that the syntax with `=` is the preferred one stylistically. However, when it comes to `alias this` declarations, the only syntax supported is `alias other this;`, and one cannot write `alias this = other;`. Does this mean that the `alias other aliasName;` syntax is preferred, or does it simply mean that this is a low priority issue that hasn't been addressed yet?
Re: Visual D 0.47.0 released
On 26/06/2018 16:25, Robert M. Münch wrote: On 2018-06-24 13:08:53 +, Rainer Schuetze said: a new release of Visual D has just been uploaded. Major changes are * improved Visual C++ project integration: better dependencies, automatic libraries, name demangling * new project wizard * mago debugger: show vtable, dynamic type of interfaces, symbol names of pointer address As soon as I use the Mago debugger, it's impossible to start a debugging session. Any idea how to track down such a problem? Works for me, can you give more details? VS version, platform, etc. Please note that there is no need to select the Mago debug engine in VS2013 or later. Since a couple of versions of Visual D, the VS debugger is equipped with an extension based on Mago that can evaluate D expressions.
