[Issue 18262] New: stdx.allocator.building_blocks.bitmapped_block has spurious failures on the auto-tester

https://issues.dlang.org/show_bug.cgi?id=18262 Issue ID: 18262 Summary: stdx.allocator.building_blocks.bitmapped_block has spurious failures on the auto-tester Product: D Version: D2 Hardware: x86_64 OS: Mac

[Issue 18151] New: wrong auto ref lvalue inference for implicitly converted alias this parameters

https://issues.dlang.org/show_bug.cgi?id=18151 Issue ID: 18151 Summary: wrong auto ref lvalue inference for implicitly converted alias this parameters Product: D Version: D2 Hardware: All OS: All

Re: Please do not use 'auto' return types without thoroughly describing the interface

nts? For instance, for the function: auto map(Range)(Range r) if (isInputRange!(Unqual!Range)); we'd add the following to its constraints: isInputRange!(ReturnType!(map!R)) However, this does not compile at the moment. I'm not sure why. I'm not sure why either, but signature constrai

Re: Please do not use 'auto' return types without thoroughly describing the interface

patible is an iffy proposition at best. Keeping the return types opaque helps to discourage this sort of misplaced assumption in user code. > Like I might read the docs and, quite reasonably, write: > > auto capture = needFirst ? matchFirst(str, regex) : matchAll(str, > regex).skip

Re: Please do not use 'auto' return types without thoroughly describing the interface

On Wednesday, 27 December 2017 at 16:36:59 UTC, H. S. Teoh wrote: The best we can do currently, which unfortunately won't show up in the docs, is to use a static assert to force compilation failure when the return type doesn't match expectations, e.g.: [...] static

Re: Please do not use 'auto' return types without thoroughly describing the interface

On Tue, Dec 26, 2017 at 11:28:56AM +, Mark via Digitalmars-d wrote: > On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote: > > While I agree that all template parameters ought to be documented > > and all auto return types thoroughly described, I disagree with >

Re: Please do not use 'auto' return types without thoroughly describing the interface

On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote: On Mon, Dec 25, 2017 at 04:26:52PM +, Piotr Klos via Digitalmars-d wrote: On Monday, 25 December 2017 at 03:23:33 UTC, Neia Neutuladh wrote: > If you have a function with a return type listed as `auto`, > please thor

Re: Please do not use 'auto' return types without thoroughly describing the interface

On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote: While I agree that all template parameters ought to be documented and all auto return types thoroughly described, I disagree with explicit naming of auto return types. The whole point of auto return types is to return an *opaque

Re: Please do not use 'auto' return types without thoroughly describing the interface

a unique type for each (hello, std.typecons.Typedef). Like I might read the docs and, quite reasonably, write: auto capture = needFirst ? matchFirst(str, regex) : matchAll(str, regex).skip(3).front; auto process = asShell ? spawnShell("echo hi") : spawnProcess(["/bin/echo",

[Issue 18124] Over-use of `auto` return type in std.regex

https://issues.dlang.org/show_bug.cgi?id=18124 --- Comment #3 from Seb --- > I wasn't aware that a decision to use the type system was bikeshedding. Okay let me go one step back here: I do see your point of explicitly stating the return type, s.t. it's one click away

Re: Please do not use 'auto' return types without thoroughly describing the interface

On Mon, Dec 25, 2017 at 04:26:52PM +, Piotr Klos via Digitalmars-d wrote: > On Monday, 25 December 2017 at 03:23:33 UTC, Neia Neutuladh wrote: > > If you have a function with a return type listed as `auto`, please > > thoroughly describe what interface the return value provid

[Issue 18124] Over-use of `auto` return type in std.regex

https://issues.dlang.org/show_bug.cgi?id=18124 --- Comment #2 from Neia Neutuladh --- I wasn't aware that a decision to use the type system was bikeshedding. Just a tip: emoticons can make an otherwise professional comment seem smarmy or condescending. If you do not intend

[Issue 18124] Over-use of `auto` return type in std.regex

CC||greensunn...@gmail.com Resolution|--- |WONTFIX --- Comment #1 from Seb <greensunn...@gmail.com> --- Advantage of `auto`: - we can change the API - less visual clutter (that's subjective though) See the discussion at https:

Re: Please do not use 'auto' return types without thoroughly describing the interface

On Monday, 25 December 2017 at 03:23:33 UTC, Neia Neutuladh wrote: If you have a function with a return type listed as `auto`, please thoroughly describe what interface the return value provides. I would just like to say that I strongly agree. Lack of documentation of template parameters

Re: Please do not use 'auto' return types without thoroughly describing the interface

I would like to fix this using signatures[0]. Signatures have a number of benefits here, including removing of TypeInfo (which prevents code-bloat). There is a few other examples based upon allocators here[1]. But this isn't a short term goal even if it does get approved ;) [0]

Please do not use 'auto' return types without thoroughly describing the interface

If you have a function with a return type listed as `auto`, please thoroughly describe what interface the return value provides. "Returns a forward range of Elem", where Elem is a template parameter, is fine, for instance. But look at std.regex.RegexMatch.front: &quo

[Issue 18124] New: Over-use of `auto` return type in std.regex

https://issues.dlang.org/show_bug.cgi?id=18124 Issue ID: 18124 Summary: Over-use of `auto` return type in std.regex Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement

[Issue 17935] [scope] auto-generated destructor not scope aware

https://issues.dlang.org/show_bug.cgi?id=17935 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/c9ff5810a2f449f19a39172461d511c895dcb519 fix Issue 17935 - [scope] auto-generated destructor not scope

mysql-native v1.1.4: Introduced auto-purge to fix a few problems

An all-D MySQL/MariaDB client library: https://github.com/mysql-d/mysql-native In v1.1.4: Introduced auto-purge to fix a few problems. - Fixed: #117: ResultRange cannot be copied. (@Abscissa) - Fixed: #119: Is a defensive

[Issue 18000] New: [scope] auto-generated opAssign not scope aware

https://issues.dlang.org/show_bug.cgi?id=18000 Issue ID: 18000 Summary: [scope] auto-generated opAssign not scope aware Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal

[Issue 17992] New: auto return type and null for classes

https://issues.dlang.org/show_bug.cgi?id=17992 Issue ID: 17992 Summary: auto return type and null for classes Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1

[Issue 17935] [scope] auto-generated destructor not scope aware

https://issues.dlang.org/show_bug.cgi?id=17935 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/c9ff5810a2f449f19a39172461d511c895dcb519 fix Issue 17935 - [scope] auto-generated destructor not scope

[Issue 17935] [scope] auto-generated destructor not scope aware

https://issues.dlang.org/show_bug.cgi?id=17935 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 17968] object initializer for auto function not included when seen through 2 libraries

https://issues.dlang.org/show_bug.cgi?id=17968 --- Comment #1 from Steven Schveighoffer --- 2.075.0 still has the same problem. --

[Issue 17968] New: object initializer for auto function not included when seen through 2 libraries

https://issues.dlang.org/show_bug.cgi?id=17968 Issue ID: 17968 Summary: object initializer for auto function not included when seen through 2 libraries Product: D Version: D2 Hardware: All OS: All

[Issue 17935] [scope] auto-generated destructor not scope aware

https://issues.dlang.org/show_bug.cgi?id=17935 --- Comment #1 from Walter Bright --- https://github.com/dlang/dmd/pull/7283 --

[Issue 17935] New: [scope] auto-generated destructor not scope aware

https://issues.dlang.org/show_bug.cgi?id=17935 Issue ID: 17935 Summary: [scope] auto-generated destructor not scope aware Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: safe

Re: what means... auto ref Args args?

On Thursday, 19 October 2017 at 01:05:28 UTC, Jonathan M Davis wrote: On Thursday, October 19, 2017 00:00:54 Dave Jones via That's likely the main reason in this case, since losing the ref-ness could definitely cause issues with some constructors, but auto ref is frequently used simply

Re: what means... auto ref Args args?

I noticed... > >> > >> T* emplace(T, Args...)(T* chunk, auto ref Args args) > >> > >> what does the "auto ref" do in this situiation? Cant seem to > >> find any explanation in the docs. > > > > It means that any argument (tha

Re: what means... auto ref Args args?

On Wednesday, 18 October 2017 at 22:16:32 UTC, Moritz Maxeiner wrote: On Wednesday, 18 October 2017 at 21:38:41 UTC, Dave Jones wrote: Poking around in the source code for emplace and I noticed... T* emplace(T, Args...)(T* chunk, auto ref Args args) what does the "auto re

Re: what means... auto ref Args args?

On Wednesday, 18 October 2017 at 21:38:41 UTC, Dave Jones wrote: Poking around in the source code for emplace and I noticed... T* emplace(T, Args...)(T* chunk, auto ref Args args) what does the "auto ref" do in this situiation? Cant seem to find any explanation in the docs.

Re: what means... auto ref Args args?

On Wednesday, 18 October 2017 at 21:38:41 UTC, Dave Jones wrote: Poking around in the source code for emplace and I noticed... T* emplace(T, Args...)(T* chunk, auto ref Args args) what does the "auto ref" do in this situiation? Cant seem to find any explanation in the docs. s

what means... auto ref Args args?

Poking around in the source code for emplace and I noticed... T* emplace(T, Args...)(T* chunk, auto ref Args args) what does the "auto ref" do in this situiation? Cant seem to find any explanation in the docs.

Re: template auto deduction

On Friday, 6 October 2017 at 21:42:40 UTC, Steven Schveighoffer wrote: What you need is IFTI or "Implicit Function Template Instantiation" Note the "Function" part of it, in that it's only valid for functions. So you need a factory function: auto m(T)(T x

Re: template auto deduction

cool stuff } } void main() { FS!(Etype1) fs; auto m = M!(typeof(fs))(fs);    // line 21. auto a = M!(fs); // does not work auto b = M(fs); // does not work } struct FS(T...){} struct Etype1{} Everything works as expected, especially line 21. The question is about syntactic

template auto deduction

stuff } } void main() { FS!(Etype1) fs; auto m = M!(typeof(fs))(fs);// line 21. auto a = M!(fs); // does not work auto b = M(fs); // does not work } struct FS(T...){} struct Etype1{} Everything works as expected, especially line 21. The question

[Issue 15492] ICE (segfault) on class { auto f() with out contract }

https://issues.dlang.org/show_bug.cgi?id=15492 Simon Na. changed: What|Removed |Added Status|NEW |RESOLVED

Re: if (auto x = cast(C) x)

On Wednesday, 9 August 2017 at 21:54:46 UTC, Q. Schroll wrote: For a class/interface type `A` and a class `C` inheriting from `A` one can do A a = getA(); if (auto c = cast(C) a) { .. use c .. } to get a `C` view on `a` if it happens to be a `C`-instance. Sometimes one cannot find

[Issue 17388] [scope] no escape analysis for auto return scope members

|bugzi...@digitalmars.com --- Comment #1 from Walter Bright <bugzi...@digitalmars.com> --- This shrinks down a bit to: struct S { int[] // works //auto// doesn't work foo() return @safe { return x[]; } int[4] x; } @safe int[] f() { S s; return s.foo(); } --

Re: if (auto x = cast(C) x)

On Wednesday, 9 August 2017 at 21:54:46 UTC, Q. Schroll wrote: For a class/interface type `A` and a class `C` inheriting from `A` one can do A a = getA(); if (auto c = cast(C) a) { .. use c .. } to get a `C` view on `a` if it happens to be a `C`-instance. Sometimes one cannot find

if (auto x = cast(C) x)

For a class/interface type `A` and a class `C` inheriting from `A` one can do A a = getA(); if (auto c = cast(C) a) { .. use c .. } to get a `C` view on `a` if it happens to be a `C`-instance. Sometimes one cannot find a good new name for `c` while there is no advantage of accessing

[Issue 14669] auto attribute on function parameter should be error always

https://issues.dlang.org/show_bug.cgi?id=14669 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to dmd-cxx at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/366c8e9171b18d892a69d961ca4d8655ba28d1cf Issue 14669 - auto attribute on function parameter should

auto conversion to ascii

My Dynamic array complete show is good but when assign it's one index to a variable, it's saves ASCII of that index. writeln(myarray); // output 24 var = myarray[0]; // it assign 50 to var Why changed to ASCII and how to get rid of please...

[Issue 16953] auto-tester doesn't run rdmd_test (causes a number of regressions in each release)

effectively. We also have a daily cron job configured on Travis, so we can now at least be informed of such breakages shortly after they happen. Integrating the test into the auto-tester would be nice, however it currently doesn't test the tools repo at all. What might be more likely to ha

[Issue 8204] Alias causes error: "auto can only be used for template function parameters"

https://issues.dlang.org/show_bug.cgi?id=8204 --- Comment #2 from Vladimir Panteleev <dlang-bugzi...@thecybershadow.net> --- (In reply to dlang+issues from comment #0) > void foo(T)(ref auto T v) { } > alias foo!int bar; // Error: auto can only be used for template function > p

[Issue 14838] [REG 2.066] Wrong attribute inference for auto-generated class destructor with static array of non-POD type

https://issues.dlang.org/show_bug.cgi?id=14838 Vladimir Panteleev changed: What|Removed |Added See Also|

Re: Auto-decoding

On Saturday, 15 July 2017 at 18:47:25 UTC, Joakim wrote: On Saturday, 15 July 2017 at 18:14:48 UTC, aberba wrote: So what is the current plan? :) Andrei has talked about having a non-auto-decoding path for those who know what they're doing and actively choose that path, while keeping auto

Re: Auto-decoding

On Saturday, 15 July 2017 at 18:14:48 UTC, aberba wrote: On Saturday, 15 July 2017 at 05:54:32 UTC, ag0aep6g wrote: On 07/15/2017 06:21 AM, bauss wrote: [...] 1) Drop two elements from "Bär". With auto-decoding you get "r", which is nice. Without auto-decoding you ge

Re: Auto-decoding

On 07/15/2017 08:14 PM, aberba wrote: So what is the current plan? :) As far as I'm aware, there's no concrete plan to change anything. We just gotta deal with auto-decoding for the time being.

Re: Auto-decoding

On Saturday, 15 July 2017 at 05:54:32 UTC, ag0aep6g wrote: On 07/15/2017 06:21 AM, bauss wrote: [...] 1) Drop two elements from "Bär". With auto-decoding you get "r", which is nice. Without auto-decoding you get [0xA4, 'r'] where 0xA4 is the second half of the encod

Re: Auto-decoding

On 07/15/2017 06:21 AM, bauss wrote: I understand what it is and how it works, but I don't understand anything of how it solves any problems? Could someone give an example of when auto-decoding actually is useful in contrast to not using it? 1) Drop two elements from "Bär".

Auto-decoding

I understand what it is and how it works, but I don't understand anything of how it solves any problems? Could someone give an example of when auto-decoding actually is useful in contrast to not using it? Just trying to get an understanding of what exactly its purpose is. I did read

[Issue 12372] Forward reference error with auto type inference in overloaded functions

https://issues.dlang.org/show_bug.cgi?id=12372 Vladimir Panteleev changed: What|Removed |Added Status|NEW

Re: auto*

000, Meta via > Digitalmars-d wrote: > > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > > > Create an auto pointer, handy in some cases and fits in > > > the language as a natural generalization. > > > > It's been suggested before (as well as mo

Re: auto*

On Thursday, 6 July 2017 at 20:24:24 UTC, FoxyBrown wrote: On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d wrote: Create an auto pointer, handy in some cases and fits in the language as a natural generalization

Re: auto*

On Friday, 7 July 2017 at 00:58:57 UTC, jmh530 wrote: On Friday, 7 July 2017 at 00:39:32 UTC, Meta wrote: (https://github.com/dlang/dmd/pull/3615) Of course this could also get confusing pretty fast. I wish we at least had the `int[$]` syntax but it's not a huge loss. Thanks for posting

Re: auto*

On Friday, 7 July 2017 at 00:39:32 UTC, Meta wrote: (https://github.com/dlang/dmd/pull/3615) Of course this could also get confusing pretty fast. I wish we at least had the `int[$]` syntax but it's not a huge loss. Thanks for posting the link. Made for interesting reading. This was

Re: auto*

On Thursday, 6 July 2017 at 23:51:13 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via Digitalmars-d wrote: [...] Let's say you have. auto a = foo(); You have no idea what auto actually is in that case, but auto* a = foo(); You know auto is a pointer of whatever foo

Re: auto*

On Thursday, 6 July 2017 at 23:51:13 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via Digitalmars-d wrote: [...] Let's say you have. auto a = foo(); You have no idea what auto actually is in that case, but auto* a = foo(); You know auto is a pointer of whatever foo

Re: auto*

On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via Digitalmars-d wrote: [...] > Let's say you have. > > auto a = foo(); > > You have no idea what auto actually is in that case, but > > auto* a = foo(); > > You know auto is a pointer of whatever foo returns. Ah,

Re: auto*

sday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > > > Create an auto pointer, handy in some cases and fits in > > > the language as a natural generalization. > > > > It's been suggested before (as well as more powerful > > generalization for slices and a

Re: auto*

On Thu, Jul 06, 2017 at 10:31:10PM +, Meta via Digitalmars-d wrote: > On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote: > > On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via Digitalmars-d wrote: > > > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: >

Re: auto*

On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via Digitalmars-d wrote: On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > Create an auto pointer, handy in some cases and fits in the > language as a natural generali

Re: auto*

On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via Digitalmars-d wrote: > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > > Create an auto pointer, handy in some cases and fits in the language > > as a natural generalization. > > It's been suggested before (as

Re: auto*

On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: Create an auto pointer, handy in some cases and fits in the language as a natural generalization. It's been suggested before (as well as more powerful generalization for slices and associative arrays), but Andrei vetoed it so

Re: auto*

On 07/06/2017 01:24 PM, FoxyBrown wrote: > On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote: >> On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d >> wrote: >>> Create an auto pointer, handy in some cases and fits in the language >>

Re: auto*

On Thu, Jul 06, 2017 at 08:24:24PM +, FoxyBrown via Digitalmars-d wrote: [...] > auto x = ... > > auto* x = ... > > auto* is the pointerized version of auto. > > > e.g., > > int x = ... > > int* x = ... > > typeof(x) y = ... > type

Re: auto*

On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d wrote: Create an auto pointer, handy in some cases and fits in the language as a natural generalization. What's an auto pointer? T is it not obvious? auto x

Re: auto*

On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d wrote: > Create an auto pointer, handy in some cases and fits in the language > as a natural generalization. What's an auto pointer? T -- Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are

auto*

Create an auto pointer, handy in some cases and fits in the language as a natural generalization.

[Issue 15368] Improve error message for "auto" keyword inside "foreach"

https://issues.dlang.org/show_bug.cgi?id=15368 Vladimir Panteleev changed: What|Removed |Added Keywords|

[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of "auto ref" and "return" attribute deduction.

https://issues.dlang.org/show_bug.cgi?id=17512 Vladimir Panteleev changed: What|Removed |Added CC|

Nullable with auto-allocation on access

Is there a construct similar to Nullable that would auto-allocate upon access (set/get) if isNull is true? Use case: https://github.com/msoucy/dproto/issues/117 [getters and setters should work without calling `init` on Nullable fields, as in C++ #117] copied inline for easy reference: ``` in C

[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of "auto ref" and "return" attribute deduction.

|safe CC||petar.p.ki...@gmail.com Summary|[REG 2.073] Error on bad|[REG 2.073] [DIP1000] Error |interplay of "auto ref" and |on bad interplay of "auto |"return" attribute

[Issue 17512] [REG 2.073] Error on bad interplay of "auto ref" and "return" attribute deduction.

|returning a reference to|interplay of "auto ref" and |local variable |"return" attribute ||deduction. Severity|normal |regression --

Re: auto decoding rant

On Thursday, 15 June 2017 at 15:50:42 UTC, Seb wrote: On Thursday, 15 June 2017 at 15:47:54 UTC, Jonathan Shamir wrote: Also note I can't cast to char[] in compile time? What's the reason for that? Have a look at: https://dlang.org/phobos/std_utf.html#byCodeUnit

Re: auto decoding rant

s the > reason for that? > > I would recommend adding something like this to phobos (and in > all fairness, it should have been the other way around): Yes, it should be the other way around, but changing it at this point without massive code breakage is very difficult if not impo

Re: auto decoding rant

On Thursday, 15 June 2017 at 15:47:54 UTC, Jonathan Shamir wrote: Also note I can't cast to char[] in compile time? What's the reason for that? Have a look at: https://dlang.org/phobos/std_utf.html#byCodeUnit https://dlang.org/phobos/std_utf.html#byChar

auto decoding rant

other way around): auto noDecode(T)(T[] str) if (isNarrowString!(T[])) { static struct NoDecode { private T[] str; @property ref T front() { assert (!this.empty); return str[0]; } @property bool empty() { return

Re: Make enum auto castable

On Monday, 5 June 2017 at 03:15:46 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 02:14:14 Mike B Johnson via Digitalmars-d-learn wrote: On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote: > On Monday, June 05, 2017 01:30:47 Mike B Johnson via > > Digitalmars-d-learn wrote:

Re: Make enum auto castable

On Sun, Jun 04, 2017 at 08:15:46PM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: > Well, implicit conversions tend to cause a lot of bugs in C++ code, so > Walter decided to restrict them quite a bit more in D than they are in C++. So D has plenty of implicit conversion. It is implicit

Re: Make enum auto castable

On Monday, June 05, 2017 02:14:14 Mike B Johnson via Digitalmars-d-learn wrote: > On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote: > > On Monday, June 05, 2017 01:30:47 Mike B Johnson via > > > > Digitalmars-d-learn wrote: > >> [...] > > > > It's not a bug. The alias this

Re: Make enum auto castable

On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 01:30:47 Mike B Johnson via Digitalmars-d-learn wrote: [...] It's not a bug. The alias this conversion only goes one way. It provides a way to convert _from_ the type that it's declared on to another

Re: Make enum auto castable

On Monday, June 05, 2017 01:30:47 Mike B Johnson via Digitalmars-d-learn wrote: > enum X : EnumX > { > a = 1, > } > > > struct EnumX > { > int x; > alias x this; > void opAssign(int y) > { > x = y; > } > double opCall() > { > return x; > } > } > > doesn't

Re: Make enum auto castable

On Monday, 5 June 2017 at 00:51:15 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 00:16:15 Mike B Johnson via Digitalmars-d-learn wrote: On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote: > [...] I might be able to change the enum, I assume you mean something like enum

Re: Make enum auto castable

On Monday, June 05, 2017 01:12:20 Mike B Johnson via Digitalmars-d-learn wrote: > Well, I do need to to treat it as an int at times and opCast only > works with cast. While I could set it up to do a cast(VARIANT), > which is better than nothing, I'd get same result as to!VARIANT, > which is

Re: Make enum auto castable

On Monday, 5 June 2017 at 00:51:15 UTC, Jonathan M Davis wrote: On Monday, June 05, 2017 00:16:15 Mike B Johnson via Digitalmars-d-learn wrote: On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote: > On Sunday, June 04, 2017 22:52:55 Mike B Johnson via > > Digitalmars-d-learn wrote:

Re: Make enum auto castable

On Monday, June 05, 2017 00:16:15 Mike B Johnson via Digitalmars-d-learn wrote: > On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote: > > On Sunday, June 04, 2017 22:52:55 Mike B Johnson via > > > > Digitalmars-d-learn wrote: > >> [...] > > > > Aside from whatever implicit conversions

Re: Make enum auto castable

On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote: On Sunday, June 04, 2017 22:52:55 Mike B Johnson via Digitalmars-d-learn wrote: [...] Aside from whatever implicit conversions are built into the language, the only way to define an implicit conversion in D is via alias this on

Re: Make enum auto castable

ich has historically forced folks to do stuff like Nullable!int(42) when passing the actual type to a function that accepts a Nullable wrapper around the type, which is pretty annoying. Recently, a nullable function was added to std.typecons which uses IFTI to infer the type of the Nullable a

Re: Make enum auto castable

On Sunday, 4 June 2017 at 22:52:55 UTC, Mike B Johnson wrote: I am dealing with some COM stuff and some functions use VARIANT, which can hold an enum. Instead of having to manually convert the enum(and for that matter, other things) to VARIANT, is it possible to have them automatically

Make enum auto castable

I am dealing with some COM stuff and some functions use VARIANT, which can hold an enum. Instead of having to manually convert the enum(and for that matter, other things) to VARIANT, is it possible to have them automatically converted? This is because an enum is always convertible to a

[Issue 17444] std.traits.isCallable doesn't recognize struct member function if return type is 'auto'.

https://issues.dlang.org/show_bug.cgi?id=17444 --- Comment #3 from uplink.co...@googlemail.com --- I would classify this as a bug, however it seems like a fix for this would break other situations. for now the best workaround is to not use functions returning auto inside that struct. --

[Issue 17444] std.traits.isCallable doesn't recognize struct member function if return type is 'auto'.

https://issues.dlang.org/show_bug.cgi?id=17444 --- Comment #2 from Dario Schiavon --- (In reply to uplink.coder from comment #1) > This has to do with the order of symbol resolving. > You will see that it will print good, if you put the static if outside of > the struct

[Issue 17444] std.traits.isCallable doesn't recognize struct member function if return type is 'auto'.

https://issues.dlang.org/show_bug.cgi?id=17444 uplink.co...@googlemail.com changed: What|Removed |Added CC||uplink.co...@googlemail.com

[Issue 17444] New: std.traits.isCallable doesn't recognize struct member function if return type is 'auto'.

https://issues.dlang.org/show_bug.cgi?id=17444 Issue ID: 17444 Summary: std.traits.isCallable doesn't recognize struct member function if return type is 'auto'. Product: D Version: D2 Hardware: x86 OS

[Issue 17388] [scope] no escape analysis for auto return scope members

CC||c...@dawg.eu Summary|[DIP1000] no escape |[scope] no escape analysis |analysis for auto return |for auto return scope |scope members |members --

[Issue 17388] New: [DIP1000] no escape analysis for auto return scope members

https://issues.dlang.org/show_bug.cgi?id=17388 Issue ID: 17388 Summary: [DIP1000] no escape analysis for auto return scope members Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

template auto switch_(Any& a) { return [](auto ...cases_) { auto cases = hana::make_tuple(cases_...); auto default_ = hana::find_if(cases, [](auto const& c) { return hana:

template auto switch_(Any& a) { return [](auto ...cases_) { auto cases = hana::make_tuple(cases_...); auto default_ = hana::find_if(cases, [](auto const& c) { return hana::first(c) == hana::type_c; }); // ... }; }

Re: if auto and method call

On Tuesday, 18 April 2017 at 09:05:10 UTC, Andrea Fontana wrote: On Tuesday, 18 April 2017 at 00:48:05 UTC, Jethro wrote: How to combine the need to localize a result for an if statement and have to call a method to get proper comparison: [...] which should simplify to if ((auto x = foo

<    3   4   5   6   7   8   9   10   11   12   >