[Issue 12924] deprecated("foo"); and deprecated; should not compile
https://issues.dlang.org/show_bug.cgi?id=12924
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/4b2578e208f2af9a02159fc2d8d87fb17b09005e
fix Issue 12924 - deprecated("foo"); and deprecated; should not compile
'DeclarationBlock' that follows 'Attribute' should be parsed by parseBlock.
`PrefixAttribute` is used to check redundant/conflicting attributes over the
mutual call between `parseDeclDefs` and `parseBlock`.
https://github.com/D-Programming-Language/dmd/commit/77f4e95af6cf1fd2dd80902ec122a23f1358fd1f
Merge pull request #3676 from 9rnsr/fix12924
[REG2.066a] Issue 12924 - deprecated("foo"); and deprecated; should not compile
--
[Issue 12924] deprecated("foo"); and deprecated; should not compile
https://issues.dlang.org/show_bug.cgi?id=12924 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12940] New: std.bigint.Bigint.toSize_t too, and alternative API suggestion
https://issues.dlang.org/show_bug.cgi?id=12940 Issue ID: 12940 Summary: std.bigint.Bigint.toSize_t too, and alternative API suggestion Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: bearophile_h...@eml.cc std.bigint.Bigint has toInt/toLong methods: const pure long toLong(); Returns the value of this BigInt as a long, or +- long.max if outside the representable range. const pure int toInt(); Returns the value of this BigInt as an int, or +- int.max if outside the representable range. I think it's also useful a "toSize_t" method, to use bigInts for array indexes. Another unrelated idea is to change the behavour for the cases when the value is outside the representable range, returning a Nullable!int, Nullable!long or Nullable!size_t that is null in case of overflow. (In general I think Phobos should start using std.typecons.Nullable more often.) --
[Issue 10897] btc, btr and bts shouldn't be safe
https://issues.dlang.org/show_bug.cgi?id=10897 David Nadlinger changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@klickverbot.at Resolution|--- |FIXED --- Comment #5 from David Nadlinger --- Fixed since quite some while. --
[Issue 5270] Using a scope delegate allows memory corruption in safe mode
https://issues.dlang.org/show_bug.cgi?id=5270 David Nadlinger changed: What|Removed |Added Keywords||safe CC||c...@klickverbot.at --
[Issue 8838] Slicing static arrays should be considered unsafe (@system)
https://issues.dlang.org/show_bug.cgi?id=8838 David Nadlinger changed: What|Removed |Added Keywords||safe CC||c...@klickverbot.at --
[Issue 8752] Unsafe use of T.init should be allowed in @system function
https://issues.dlang.org/show_bug.cgi?id=8752 David Nadlinger changed: What|Removed |Added Keywords||safe CC||c...@klickverbot.at --
[Issue 12939] More uniform error messages for not nothrow and not @safe functions
https://issues.dlang.org/show_bug.cgi?id=12939 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 12931] Make const, immutable, and inout illegal as funtion attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 12845] @safe std.algorithm.remove on array of tuples
https://issues.dlang.org/show_bug.cgi?id=12845 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 12527] Cannot make @system function/delegate alias in a @safe section
https://issues.dlang.org/show_bug.cgi?id=12527 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 12561] typeof function literal doesn't check @safe
https://issues.dlang.org/show_bug.cgi?id=12561 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 11466] std.range.zip for nothrow and @safe functions
https://issues.dlang.org/show_bug.cgi?id=11466 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 11176] array.ptr in @safe code
https://issues.dlang.org/show_bug.cgi?id=11176 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 11047] UDA + getAttributes bypass purity/safety check
https://issues.dlang.org/show_bug.cgi?id=11047 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 10512] Reinterpret-casting struct fields as another struct should be @safe
https://issues.dlang.org/show_bug.cgi?id=10512 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 10297] Memory safe D spec is out of date
https://issues.dlang.org/show_bug.cgi?id=10297 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 9246] safe struct with dtor doesn't generate safe opAssign
https://issues.dlang.org/show_bug.cgi?id=9246 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 12939] More uniform error messages for not nothrow and not @safe functions
https://issues.dlang.org/show_bug.cgi?id=12939 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 12561] typeof function literal doesn't check @safe
https://issues.dlang.org/show_bug.cgi?id=12561 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 11466] std.range.zip for nothrow and @safe functions
https://issues.dlang.org/show_bug.cgi?id=11466 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 12931] Make const, immutable, and inout illegal as funtion attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 12527] Cannot make @system function/delegate alias in a @safe section
https://issues.dlang.org/show_bug.cgi?id=12527 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 10512] Reinterpret-casting struct fields as another struct should be @safe
https://issues.dlang.org/show_bug.cgi?id=10512 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 11176] array.ptr in @safe code
https://issues.dlang.org/show_bug.cgi?id=11176 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 11047] UDA + getAttributes bypass purity/safety check
https://issues.dlang.org/show_bug.cgi?id=11047 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 10297] Memory safe D spec is out of date
https://issues.dlang.org/show_bug.cgi?id=10297 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 9246] safe struct with dtor doesn't generate safe opAssign
https://issues.dlang.org/show_bug.cgi?id=9246 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 8131] Delegate type inference with templates is absolutely *horrible*
https://issues.dlang.org/show_bug.cgi?id=8131 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 8131] Delegate type inference with templates is absolutely *horrible*
https://issues.dlang.org/show_bug.cgi?id=8131 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||rejects-valid --
[Issue 8131] Delegate type inference with templates is absolutely *horrible*
https://issues.dlang.org/show_bug.cgi?id=8131 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||diagnostic --
[Issue 6646] [SafeD] array.reserve is not @safe/trusted
https://issues.dlang.org/show_bug.cgi?id=6646 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 6644] std.stdio write/writef(ln) are not @trusted
https://issues.dlang.org/show_bug.cgi?id=6644 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe CC||hst...@quickfur.ath.cx --
[Issue 6405] @safe doesn't work with multidimensional typesafe variadic parameters
https://issues.dlang.org/show_bug.cgi?id=6405 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe CC||hst...@quickfur.ath.cx --
[Issue 12931] Make const, immutable, and inout illegal as funtion attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 Jonathan M Davis changed: What|Removed |Added Keywords|safe| --
[Issue 6333] The 'capacity' function is not pure/nothrow/@safe.
https://issues.dlang.org/show_bug.cgi?id=6333 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe CC||hst...@quickfur.ath.cx --
[Issue 5305] intrinsic functions have @safe stripped of them in release mode.
https://issues.dlang.org/show_bug.cgi?id=5305 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe CC||hst...@quickfur.ath.cx --
[Issue 6278] Regression(2.054 beta): 'in' contract inheritance doesn't work with safe code
https://issues.dlang.org/show_bug.cgi?id=6278 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe CC||hst...@quickfur.ath.cx --
[Issue 4222] druntime should apply @safe/@system/@trusted
https://issues.dlang.org/show_bug.cgi?id=4222 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe CC||hst...@quickfur.ath.cx --
[Issue 4221] dmd should not allow overload between @safe/@trusted and @system
https://issues.dlang.org/show_bug.cgi?id=4221 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe CC||hst...@quickfur.ath.cx --
[Issue 12931] Make const, immutable, and inout illegal as funtion attributes on the left-hand side of a function
https://issues.dlang.org/show_bug.cgi?id=12931 Jonathan Crapuchettes changed: What|Removed |Added CC||jcrapuchet...@gmail.com --- Comment #2 from Jonathan Crapuchettes --- I'm in agreement. It would be really nice to have this disallowed for the sake of new people coming to the language. It can be very confusing. --
[Issue 3462] Add a clean way to exit a process.
https://issues.dlang.org/show_bug.cgi?id=3462 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 12941] New: Everything should be @unsafe by default, and explicitly vetted (and documented) as @safe
https://issues.dlang.org/show_bug.cgi?id=12941 Issue ID: 12941 Summary: Everything should be @unsafe by default, and explicitly vetted (and documented) as @safe Product: D Version: D2 Hardware: x86 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: hst...@quickfur.ath.cx Since everyone keeps talking about this in the NG but nobody does anything about it, I'll put myself in the firing range and do it. Basically, the compiler should treat everything as non-@safe, except for a list of @safe operations that is well-defined and well-documented. For starters, let's make a list of operations that are known to be @safe on this bug, and once the list is reasonably complete, we can start looking at the compiler sources to tweak the current implementation to match this list. --
[Issue 12941] Everything should be @unsafe by default, and explicitly vetted (and documented) as @safe
https://issues.dlang.org/show_bug.cgi?id=12941 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||safe --
[Issue 12941] Everything should be @unsafe by default, and explicitly vetted (and documented) as @safe
https://issues.dlang.org/show_bug.cgi?id=12941 deadalnix changed: What|Removed |Added CC||deadal...@gmail.com --- Comment #1 from deadalnix --- Here is my list: - The whole language Good, now that everything is @system, let's start a list of what is @safe instead. --
[Issue 12822] Delegate .ptr assignment considered @safe
https://issues.dlang.org/show_bug.cgi?id=12822 Mike Wey changed: What|Removed |Added Keywords||safe CC||m...@mikewey.eu --
[Issue 12941] Everything should be @unsafe by default, and explicitly vetted (and documented) as @safe
https://issues.dlang.org/show_bug.cgi?id=12941 --- Comment #2 from hst...@quickfur.ath.cx --- Um, isn't that stating the obvious? I thought I made it clear that the list was supposed to be a list of @safe constructs, not a list of un-@safe constructs. --
[Issue 12886] std.datetime cannot parse HTTP date
https://issues.dlang.org/show_bug.cgi?id=12886 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/daab9927fa0e7c224e1b2200c2c287957580aa03 Implement issue# 12886: function for parsing RFC822/5322 date-time format. The RFC 822 / 5322 date-time format should be taken out and shot, but unfortunately, it _is_ used in e-mail, HTTP, RTSP, etc. Most code which deals with it is probably going to need to handle the rest of whatever spec it's interacting with rather than just the date-time format, but there are cases where this would be useful on its own (e.g. Martin apparently needs something like this in the dmd installer), so I'm adding a function to parse this format and return a SysTime to std.datetime. However, that's all I'm adding. I find it very hard to believe that anyone who needs to produce this particular format doesn't need a lot of other functionality specific to whatever spec they're dealing with, and the function for generating the date-time format presumably will be included with that (and I definitely don't want to encourage this format's use anyway, since it's a horrible format). So, I'm just adding a function for parsing the format, not generating it. parseRFC822DateTime _should_ fully and correctly implement the format as outlined in RFC 5322 (including the obsolete syntax from RFC 822 that no one is supposed to be generating anymore and the comment folding whitespace nonsense that should never have been legal anywhere but at the end). And the tests are quite thorough, so it's unlikely that I missed anything, but you never know. https://github.com/D-Programming-Language/phobos/commit/e63514cea498c1b97a36cec3c93058fbc18eac17 Merge pull request #2253 from jmdavis/rfc822 Implement issue# 12886: function for parsing RFC822/5322 date-time format. --
[Issue 12886] std.datetime cannot parse HTTP date
https://issues.dlang.org/show_bug.cgi?id=12886 Dmitry Olshansky changed: What|Removed |Added Status|NEW |RESOLVED CC||dmitry.o...@gmail.com Resolution|--- |FIXED --
[Issue 12942] New: ICE in centos
https://issues.dlang.org/show_bug.cgi?id=12942 Issue ID: 12942 Summary: ICE in centos Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: ellery-newco...@utulsa.edu In centos 6.5 I pull down the 2.065 branch of dmd, druntime and the rest from github. When I attempt to build druntime, I am met with this: /tmp/tmp.bPq5iMF46X/usr/bin/dmd -c -fPIC -oflib/libdruntime-linux64so.o -m64 -O -release -inline -w -Isrc -Iimport -fPIC -version=Shared -version=Shared src/object_.d src/core/atomic.d src/core/bitop.d src/core/cpuid.d src/core/demangle.d src/core/exception.d src/core/math.d src/core/memory.d src/core/runtime.d src/core/simd.d src/core/thread.d src/core/time.d src/core/vararg.d src/core/internal/hash.d src/core/internal/convert.d src/core/stdc/config.d src/core/stdc/ctype.d src/core/stdc/errno.d src/core/stdc/math.d src/core/stdc/signal.d src/core/stdc/stdarg.d src/core/stdc/stdio.d src/core/stdc/stdlib.d src/core/stdc/stdint.d src/core/stdc/stddef.d src/core/stdc/string.d src/core/stdc/time.d src/core/stdc/wchar_.d src/core/sync/barrier.d src/core/sync/condition.d src/core/sync/config.d src/core/sync/exception.d src/core/sync/mutex.d src/core/sync/rwmutex.d src/core/sync/semaphore.d src/core/sys/freebsd/execinfo.d src/core/sys/freebsd/sys/event.d src/core/sys/posix/signal.d src/core/sys/posix/dirent.d src/core/sys/posix/sys/resource.d src/core/sys/posix/sys/select.d src/core/sys/posix/sys/socket.d src/core/sys/posix/sys/stat.d src/core/sys/posix/sys/wait.d src/core/sys/posix/netdb.d src/core/sys/posix/sys/ioctl.d src/core/sys/posix/sys/utsname.d src/core/sys/posix/netinet/in_.d src/core/sys/windows/dbghelp.d src/core/sys/windows/dll.d src/core/sys/windows/stacktrace.d src/core/sys/windows/threadaux.d src/core/sys/windows/windows.d src/gc/gc.d src/gc/os.d src/gc/bits.d src/gc/stats.d src/gc/proxy.d src/rt/aApply.d src/rt/aApplyR.d src/rt/aaA.d src/rt/adi.d src/rt/alloca.d src/rt/arrayassign.d src/rt/arraybyte.d src/rt/arraycast.d src/rt/arraycat.d src/rt/arraydouble.d src/rt/arrayfloat.d src/rt/arrayint.d src/rt/arrayreal.d src/rt/arrayshort.d src/rt/cast_.d src/rt/cmath2.d src/rt/cover.d src/rt/critical_.d src/rt/deh.d src/rt/deh_win32.d src/rt/deh_win64_posix.d src/rt/dmain2.d src/rt/invariant.d src/rt/lifetime.d src/rt/llmath.d src/rt/memory.d src/rt/memset.d src/rt/minfo.d src/rt/monitor_.d src/rt/obj.d src/rt/qsort.d src/rt/sections.d src/rt/sections_freebsd.d src/rt/sections_linux.d src/rt/sections_osx.d src/rt/sections_solaris.d src/rt/sections_win32.d src/rt/sections_win64.d src/rt/switch_.d src/rt/tlsgc.d src/rt/trace.d src/rt/util/array.d src/rt/util/container.d src/rt/util/hash.d src/rt/util/string.d src/rt/util/utf.d src/rt/typeinfo/ti_AC.d src/rt/typeinfo/ti_Acdouble.d src/rt/typeinfo/ti_Acfloat.d src/rt/typeinfo/ti_Acreal.d src/rt/typeinfo/ti_Adouble.d src/rt/typeinfo/ti_Afloat.d src/rt/typeinfo/ti_Ag.d src/rt/typeinfo/ti_Aint.d src/rt/typeinfo/ti_Along.d src/rt/typeinfo/ti_Areal.d src/rt/typeinfo/ti_Ashort.d src/rt/typeinfo/ti_byte.d src/rt/typeinfo/ti_C.d src/rt/typeinfo/ti_cdouble.d src/rt/typeinfo/ti_cfloat.d src/rt/typeinfo/ti_char.d src/rt/typeinfo/ti_creal.d src/rt/typeinfo/ti_dchar.d src/rt/typeinfo/ti_delegate.d src/rt/typeinfo/ti_double.d src/rt/typeinfo/ti_float.d src/rt/typeinfo/ti_idouble.d src/rt/typeinfo/ti_ifloat.d src/rt/typeinfo/ti_int.d src/rt/typeinfo/ti_ireal.d src/rt/typeinfo/ti_long.d src/rt/typeinfo/ti_ptr.d src/rt/typeinfo/ti_real.d src/rt/typeinfo/ti_short.d src/rt/typeinfo/ti_ubyte.d src/rt/typeinfo/ti_uint.d src/rt/typeinfo/ti_ulong.d src/rt/typeinfo/ti_ushort.d src/rt/typeinfo/ti_void.d src/rt/typeinfo/ti_wchar.d src/etc/linux/memoryerror.d /tmp/tmp.bPq5iMF46X/usr/bin/dmd -lib -oflib/libdruntime-linux64so.a lib/libdruntime-linux64so.o obj/64/errno_c.o obj/64/threadasm.o dmd: libelf.c:217: void OmToHeader(Header*, ObjModule*): Assertion `len <= 6' failed. make: *** [lib/libdruntime-linux64so.a] Aborted --
[Issue 12943] New: Duplicated error message for out of bound array index
https://issues.dlang.org/show_bug.cgi?id=12943
Issue ID: 12943
Summary: Duplicated error message for out of bound array index
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
void main() {
int[5] arr;
auto x = arr[7];
}
DMD 2.066alpha gives two error messages, where one is enough:
test.d(3,14): Error: array index 7 is out of bounds arr[0 .. 5]
test.d(3,14): Error: array index 7 is out of bounds arr[0 .. 5]
--
[Issue 12944] New: std.variant does not observe value semantics for large value types.
https://issues.dlang.org/show_bug.cgi?id=12944
Issue ID: 12944
Summary: std.variant does not observe value semantics for large
value types.
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: opantm2+db...@gmail.com
Assigning a Variant to another Variant which contains a large value type causes
both Variants to have a reference to the same value. Currently this is not a
huge issue because the only way to modify the Variant's reference to a large
value type (that is, larger than Variant.size which is 32 bytes on x64), is
through the use of peek on a struct. This will become a larger issue when
std.variant supports static arrays however.
Sample:
import std.variant;
struct Foo {
int foo;
ubyte[32] padding;
}
void main() {
Foo f;
f.foo = 3;
Variant v = f;
Variant v2 = v;
auto fp = v.peek!Foo;
fp.foo = 6;
assert(v2.get!Foo.foo == 3); // fails
}
Commenting out the padding makes this work as expected.
--
[Issue 12944] std.variant does not observe value semantics for large value types.
https://issues.dlang.org/show_bug.cgi?id=12944 --- Comment #1 from Kapps --- Also worth noting that fixing this would require all peek and operations that alter the value (i.e., opIndexAssign) to allocate if storing a reference to another Variant. https://github.com/D-Programming-Language/phobos/pull/2188#issuecomment-44763385 has some discussion on this. It could get somewhat expensive, but would only be in the rare situations where this bug could be observed. --
[Issue 6469] Compiler fails to initialize associative array: string->[string->string]
https://issues.dlang.org/show_bug.cgi?id=6469 --- Comment #5 from Kenji Hara --- *** Issue 9520 has been marked as a duplicate of this issue. *** --
[Issue 6469] Compiler fails to initialize associative array: string->[string->string]
https://issues.dlang.org/show_bug.cgi?id=6469 Kenji Hara changed: What|Removed |Added CC||vlevenf...@gmail.com --- Comment #6 from Kenji Hara --- *** Issue 12787 has been marked as a duplicate of this issue. *** --
[Issue 12787] can't nest associative arrays and arrays
https://issues.dlang.org/show_bug.cgi?id=12787 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 6469 *** --
[Issue 9520] Wrong associative array literal interpretation
https://issues.dlang.org/show_bug.cgi?id=9520 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 6469 *** --
[Issue 8864] Simpler syntax for array literal of structs from one argument
https://issues.dlang.org/show_bug.cgi?id=8864
--- Comment #2 from Kenji Hara ---
Today following style initializing is properly allwed:
struct S { this(int n) {} }
S s = 1;// translated to: T t = T(1);
As a natural conclusion, following syntax should also be accepted IMO.
S[] a = [1, 2, 3];
// For each ArrayInitializer elements, implicit struct
// constructor call of type S should be considered.
Then it could be translated to:
S[] a = [S(1), S(2), S(3)];
--
[Issue 6469] Compiler fails to initialize associative array: string->[string->string]
https://issues.dlang.org/show_bug.cgi?id=6469 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid Severity|normal |major --- Comment #7 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/3680 --
[Issue 8864] Simpler syntax for array literal of structs from one argument
https://issues.dlang.org/show_bug.cgi?id=8864 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/3680 --
[Issue 12945] New: Deprecation for legacy static opCall feature in initializing
https://issues.dlang.org/show_bug.cgi?id=12945
Issue ID: 12945
Summary: Deprecation for legacy static opCall feature in
initializing
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
It is an old feature to emulate constructor call from D1 age.
struct S {
int num;
static S opCall(int n) {
S s;
s.num = n;
return s;
}
}
void main() {
S s = 1;
// This line is translated to:
// S s = S.opCall(1);
}
But in D2, "implicit constructor call" feature properly supports such the
initializing syntax.
struct S {
int num;
this(int n) {
this.num = n;
}
}
void main() {
S s = 1;
// This line is translated to:
// S s = S(1);
}
Therefore, we can deprecate/remove the problematic opCall feature in
initializing.
--
[Issue 12945] Deprecation for legacy static opCall feature in initializing
https://issues.dlang.org/show_bug.cgi?id=12945 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis --- static opCall without any parameters should continue work though, since you can't declare a default constructor. --
[Issue 12659] Named mixin templates conflict
https://issues.dlang.org/show_bug.cgi?id=12659 Vlad Levenfeld changed: What|Removed |Added CC||vlevenf...@gmail.com --
[Issue 10502] Can't get fullyQualifiedName of a templated struct
https://issues.dlang.org/show_bug.cgi?id=10502 Vlad Levenfeld changed: What|Removed |Added CC||vlevenf...@gmail.com --
[Issue 12945] Deprecation for legacy static opCall feature in initializing
https://issues.dlang.org/show_bug.cgi?id=12945 --- Comment #2 from Kenji Hara --- (In reply to Jonathan M Davis from comment #1) > static opCall without any parameters should continue work though, since you > can't declare a default constructor. This proposal does not change it. --
