On Friday, 13 July 2018 at 20:03:37 UTC, jmh530 wrote:
On Friday, 13 July 2018 at 17:12:26 UTC, Atila Neves wrote:
[...]
Hmm, thinking on this a little more...it does seem
difficult...but I don't think the problem is with immutable
borrows. I think the issue is with the exclusivity of Rust's
On Friday, 13 July 2018 at 17:12:26 UTC, Atila Neves wrote:
Rust can do that because it enforces it at compile-time. A D
solution wouldn't be able to do anything more with immutable
borrows.
Hmm, thinking on this a little more...it does seem
difficult...but I don't think the problem is with
On Friday, 13 July 2018 at 14:47:59 UTC, jmh530 wrote:
On Friday, 13 July 2018 at 12:43:20 UTC, Atila Neves wrote:
The only thing I got from this are that "smooth references"
are like Rust's borrows. Which just gave me the idea to add
this member function to `Unique`:
scope ref T borrow();
On Friday, 13 July 2018 at 14:47:59 UTC, jmh530 wrote:
Sounds interesting.
I imagine you could specialize this depending on mutability.
Rust allows only one mutable borrow, but eliminated
I swear I must have dyslexia or something. Eliminated should be
unlimited.
On Friday, 13 July 2018 at 12:43:20 UTC, Atila Neves wrote:
The only thing I got from this are that "smooth references" are
like Rust's borrows. Which just gave me the idea to add this
member function to `Unique`:
scope ref T borrow();
I have to think about @safety guarantees but it should
references to the same object and the
language becomes less flexible.
But yes, I assume we are in Safe Memory Management so that we
can do :
if ( isValidRef(r3) ) {
auto w = r3.getWidth();
}
Also, I have started to look at the dip-1000. At first glance,
"scope" is an approach tha
On Wednesday, 11 July 2018 at 22:46:45 UTC, xray wrote:
[ .. ]
After watching the Dconf 2018 session about "Safe Memory
Management", I told myself that, if D can guarantee an
exception in the case we delete an already deleted object, then
it's a major step forward. So le
references, we fall into the
same paradigm as Rust. Then it's going to be hard to implement
data structures with many references to the same object and the
language becomes less flexible.
But yes, I assume we are in Safe Memory Management so that we can
do :
if ( isValidRef(r3) )
On Wednesday, 11 July 2018 at 22:59:50 UTC, xray wrote:
The message above is repost of :
https://forum.dlang.org/post/pfjotkcazuiuhlvzi...@forum.dlang.org
So I can reply to Chris M. here.
--
Yes, Chris, I got inspired by Rust :)
The message above is repost of :
https://forum.dlang.org/post/pfjotkcazuiuhlvzi...@forum.dlang.org
So I can reply to Chris M. here.
--
Yes, Chris, I got inspired by Rust :) But Rust goes too far and
it lowers the productivity. N
n the current D language.
After watching the Dconf 2018 session about "Safe Memory
Management", I told myself that, if D can guarantee an exception
in the case we delete an already deleted object, then it's a
major step forward. So let's assume that.
Now, let's dist
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote:
Is it possible to introduce a new parameter/flag to the
compiler, to force all functions be @safe by default on a
per-module basis?
Forgive me if you're already aware of this, but to ensure your
entire program is `
On 6/16/18 4:27 PM, Jacob Shtokolov wrote:
On Saturday, 16 June 2018 at 18:47:10 UTC, Steven Schveighoffer wrote:
I would just caution that this does not affect member functions, only
module-level functions. You have to repeat the @safe: inside any
structs or classes as well.
Just tried that
no need to use pointers and other
> unsafe features until you really need them. In this case it's
> better to force safety for all functions by default, and it would
> be hard to do if we need to mark every single function as @safe
> (not that hard of course, but very unpleasan
attributes cannot be reversed,
mass-applying them like that can then cause problems down the
line when you need the attribute to _not_ apply to a function.
That being said, @safe is pretty much the one with the least
problems, because it's one of the ones that you can reverse by
u
On Saturday, 16 June 2018 at 18:47:10 UTC, Steven Schveighoffer
wrote:
I would just caution that this does not affect member
functions, only module-level functions. You have to repeat the
@safe: inside any structs or classes as well.
Just tried that and it works very well (throws compilation
On 6/16/18 10:02 AM, Jacob Shtokolov wrote:
On Saturday, 16 June 2018 at 13:57:48 UTC, Bastiaan Veelo wrote:
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote:
Is it possible to introduce a new parameter/flag to the compiler, to
force all functions be @safe by default on a per
eter/flag to the
> >> compiler, to force all functions be @safe by default on a
> >> per-module basis?
> >>
> >> For example:
> >>
> >> ```
> >> module mymodule;
> >>
> >> pragma(sa
On Saturday, 16 June 2018 at 14:02:36 UTC, Jacob Shtokolov wrote:
On Saturday, 16 June 2018 at 13:57:48 UTC, Bastiaan Veelo wrote:
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov
wrote:
Is it possible to introduce a new parameter/flag to the
compiler, to force all functions be @safe
On Saturday, 16 June 2018 at 13:57:48 UTC, Bastiaan Veelo wrote:
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov
wrote:
Is it possible to introduce a new parameter/flag to the
compiler, to force all functions be @safe by default on a
per-module basis?
For example:
```
module
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote:
Is it possible to introduce a new parameter/flag to the
compiler, to force all functions be @safe by default on a
per-module basis?
For example:
```
module mymodule;
pragma(safe);
We already have that, and with even shorter
Hi folks,
I know there were a lot of discussions on this topic, and it is
understandable that due to historical reasons the D language is
designed with C/C++ interop in mind, so it means that there is no
@safe by default.
However, I also see a lot of people who want this feature, and I
On Thursday, 14 June 2018 at 13:24:06 UTC, Atila Neves wrote:
I need to think about how to do isolated properly. I'll look at
vibe.d for inspiration.
Thanks. I'll have a look when you have something working.
On Thursday, 14 June 2018 at 13:24:06 UTC, Atila Neves wrote:
[snip]
I need to think about how to do isolated properly. I'll look at
vibe.d for inspiration.
I took a look at it yesterday, but the class version depended on
a long mixin that I didn't feel like fully examining...
I did notic
e restrictions.
[1] https://www.ponylang.org/
[2] http://vibed.org/api/vibe.core.concurrency/makeIsolated
What assistance can/could we currently/in-the-future get from
D's type-system to verify correctness of these paradigms?
I'm working on a library to allow @safe sharing between t
On Wednesday, 13 June 2018 at 13:50:54 UTC, Russel Winder wrote:
[snip]
Does D have move semantics at the program level or does the use
of a garbage collector abrogate the ability of a programmer to
have unique references to heap objects. Rust does this by
default and Pony allows this and oth
And yes,I do know that Pony uses a garbage collector. One with quite
interesting properties because at the top level there are only actors.
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN,
On Wed, 2018-06-13 at 09:45 +, Per Nordlöw via Digitalmars-d wrote:
> I've read up on Pony [1] and realized that it currently has a
> superior implementation of the actor model when it comes to
> combining safety, efficiency and memory management determinism
> (thread-local reference-countin
On 14/06/2018 12:13 AM, Kagamin wrote:
AFAIK, vibe has thread-local GC.
No.
On Wednesday, 13 June 2018 at 09:45:04 UTC, Per Nordlöw wrote:
I've read up on Pony [1] and realized that it currently has a
superior implementation of the actor model when it comes to
combining safety, efficiency and memory management determinism
(thread-local reference-counting GC with consen
I've read up on Pony [1] and realized that it currently has a
superior implementation of the actor model when it comes to
combining safety, efficiency and memory management determinism
(thread-local reference-counting GC with consensus guarantees)
What libraries do we have at our disposal in D
On Tuesday, 1 August 2017 at 10:01:17 UTC, Michael wrote:
On Monday, 24 July 2017 at 11:02:55 UTC, Russel Winder wrote:
On Sun, 2017-07-23 at 18:23 +, Michael via Digitalmars-d
wrote:
I stopped using it. It kept causing error messages in my
package manager and I couldn't update it properl
On Friday, 23 March 2018 at 20:33:40 UTC, Jack Stouffer wrote:
If @safe doesn't protect against buffer overflows then chuck
the whole thing out the window and start over.
Then chuck the whole thing out the window and start your own
review over and include the @safe code this time.
Yo
On Friday, 23 March 2018 at 20:33:40 UTC, Jack Stouffer wrote:
On Friday, 23 March 2018 at 17:31:09 UTC, Jesse Phillips wrote:
[...]
If @safe doesn't protect against buffer overflows then chuck
the whole thing out the window and start over.
[...]
zlib sources are included in phobo
On Friday, 23 March 2018 at 17:31:09 UTC, Jesse Phillips wrote:
@safe/@trusted doesn't mean "calling this function will not
result in heartbleed."
If @safe doesn't protect against buffer overflows then chuck the
whole thing out the window and start over.
What you're
ssue in reality with marking a
malloc/free pair as trusted when it's verified to not escape.
But there's really no garuntee about the safety of third party
libraries. What if there's a Heartbleed level bug in zlib and
we marked it as @trusted?
@safe/@trusted doesn't mean &quo
On Thursday, 22 March 2018 at 19:14:06 UTC, Seb wrote:
Making all high-level functions of Phobos @safe
---
There's are still some functions in Phobos which could be
@safe, but aren't.
I was going to ask this in Slack but since this
On 3/22/2018 12:14 PM, Seb wrote:
Making all high-level functions of Phobos @safe
---
There's are still some functions in Phobos which could be @safe, but aren't.
One of the high-level goals of 2018 [1] is:
to enable large-scale uses
Making all high-level functions of Phobos @safe
---
There's are still some functions in Phobos which could be @safe,
but aren't.
One of the high-level goals of 2018 [1] is:
to enable large-scale uses of D with safety guarantees.
So what
On 03/03/2018 12:22 AM, ag0aep6g wrote:
So am I missing something or should `tupleof` not be allowed to ignore
`private` in `@safe` code?
Filed an issue: https://issues.dlang.org/show_bug.cgi?id=18554
On 03/03/2018 12:22 AM, ag0aep6g wrote:
But what about `tupleof`? It ignores `private` and it's allowed in
`@safe` code:
[...]
Now that I've sent this, I find the affected Phobos type I couldn't
pinpoint. It's `File`:
----
void main() @safe
{
im
As far as I understand, this is generally how ref counting is supposed
to be done, and with a simple payload like `int` it's supposed to be
properly safe already:
module my_rc_thingy;
struct RCint
{
import core.stdc.stdlib: free, malloc;
private static struct
On Wednesday, 28 February 2018 at 22:34:07 UTC, Dukc wrote:
I don't think a just iterated array is automatically set to
null, so taking it's pointer won't hit a memory-proteted area.
So undeprectating arr.ptr in @safe would break @safety and be a
step backward.
If it cannot be
I don't think a just iterated array is automatically set to null,
so taking it's pointer won't hit a memory-proteted area. So
undeprectating arr.ptr in @safe would break @safety and be a step
backward.
If this is an issue, one can define a @trusted function which
takes a s
On 2/27/2018 4:39 AM, Jonathan M Davis wrote:
Except that that's really not how @trusted is supposed to be used. The
programmer needs to verify that the caller is using a.ptr in a manner that
is actually @safe, because the compiler is not smart enough to determine
that for you. Wrapping it
On Tuesday, 27 February 2018 at 11:33:04 UTC, Simen Kjærås wrote:
That only checks if the first element is the same. For a full
'is slice' check you'd need something like this:
assert(a.ptr <= b.ptr && b.ptr + b.length <= a.ptr +
a.length);
// Or:
auto c = b.ptr - a.ptr;
assert(
> Hm... borrowing from Timothee's suggestion:
> This would be fine and @safe, but may not be useful for all purposes.
> However, it would fix your issue.
how about this: https://github.com/dlang/phobos/pull/6231
On Tue, Feb 27, 2018 at 12:09 PM, Steven Schveighoffer via
Digita
with null. Well, now I can't use a
slice to call this and have it be 1) @safe and 2) not throw
RangeError. I ran into this the other way.
fun(x.length ? &x[0] : null);
Hm... borrowing from Timothee's suggestion:
@trusted @nogc pure nothrow
T* pointer(T)(T[] a){
return a.lengt
o call this and have it be 1) @safe and 2) not throw RangeError.
I ran into this the other way.
fun(x.length ? &x[0] : null);
I think even the compiler could elide the bounds check since you already
did it, but I'm not sure that actually happens.
-Steve
On 02/27/2018 06:32 PM, Atila Neves wrote:
On Tuesday, 27 February 2018 at 12:39:04 UTC, Jonathan M Davis wrote:
[...]
In almost all cases, &a[0] is equivalent to a.ptr except that it does
bounds checking, so it's actually @safe and thus doesn't need to be
manually verified by
in a manner that is actually @safe, because the compiler
is not smart enough to determine that for you. Wrapping it in
an @trusted function means that the caller won't get an error
and that the programmer won't necessarily know that they need
to verify the calling code. It's the c
r`
It isn't equivalent, but it is a @safe mechanism to do it. If you want
to do unsafe things, then you need to use @trusted escapes,
druntime/phobos is not going to help you there.
-Steve
ointer(T)(T a){
> return a.ptr;
> }
> ```
Except that that's really not how @trusted is supposed to be used. The
programmer needs to verify that the caller is using a.ptr in a manner that
is actually @safe, because the compiler is not smart enough to determine
that for you. Wrapping i
trust me, the compiler complains about both of these.
>> Possibly rightfully in the first example, but the latter never
>> does anything scary with the given pointers.
>
> As I understand it, the way that @safety checks generally work is they check
> whether a particular operat
ty checks generally work is they check
whether a particular operation is @safe or not. They don't usually care
about what is then done with the result. So, if you do something like take
the address of something, that's immediately @system regardless of what you
do with the result. That ch
/show_bug.cgi?id=18529
All I see is a rationale for how it can't be replaced, but
not a rationale for actually doing it.
I can't imagine a "safe" situation where you want to do it.
Tbh. just put your code in @trusted
Checking if an array is the slice of another.
Like?
a
can't be replaced, but not
a rationale for actually doing it.
I can't imagine a "safe" situation where you want to do it.
Tbh. just put your code in @trusted
Checking if an array is the slice of another.
Like?
assert(a.ptr != b.ptr);
Which already works in @safe.
.
I can't imagine a "safe" situation where you want to do it.
Tbh. just put your code in @trusted
Checking if an array is the slice of another.
On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour wrote:
see rationale in https://issues.dlang.org/show_bug.cgi?id=18529
All I see is a rationale for how it can't be replaced, but not a
rationale for actually doing it.
I can't imagine a "safe" situation whe
On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour wrote:
see rationale in https://issues.dlang.org/show_bug.cgi?id=18529
It looks like the actual deprecation was made with this PR:
https://github.com/dlang/dmd/pull/5860 Meaning it's been
deprecated for more than a year and a half.
see rationale in https://issues.dlang.org/show_bug.cgi?id=18529
On Wednesday, 7 February 2018 at 14:09:51 UTC, Atila Neves wrote:
auto ptr = new shared RefCounted!(...);
If you rely only on postblit, then you can't concurrently read
and write to refcounted shared storage without additional mutex
lock, so it should be at least a non-copyable container (sim
On Wednesday, 7 February 2018 at 07:58:42 UTC, Kagamin wrote:
On Tuesday, 6 February 2018 at 10:01:28 UTC, Nathan S. wrote:
You might also want to look at Atila Neves's automem package.
It uses atomic increment/decrement when the type being
reference-counted is `shared`.
https://dlang.org/blo
On Tuesday, 6 February 2018 at 10:01:28 UTC, Nathan S. wrote:
You might also want to look at Atila Neves's automem package.
It uses atomic increment/decrement when the type being
reference-counted is `shared`.
https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/
That RefCounted o
On Saturday, 3 February 2018 at 14:41:06 UTC, Kagamin wrote:
That RCSharedAllocator PR made me think, so this is my take on
how to keep reference counted allocator in shared storage:
https://run.dlang.io/is/r1z1dd
You might also want to look at Atila Neves's automem package. It
uses atomic in
That RCSharedAllocator PR made me think, so this is my take on
how to keep reference counted allocator in shared storage:
https://run.dlang.io/is/r1z1dd
On Tue, Jan 30, 2018 at 08:08:14AM +, Dukc via Digitalmars-d wrote:
> On Monday, 29 January 2018 at 17:51:40 UTC, Seb wrote:
>
> > - All high-level code should be usable in @safe
>
> This is not currently possible with functions that take a delegate
> parameter, includ
On Monday, 29 January 2018 at 17:51:40 UTC, Seb wrote:
- All high-level code should be usable in @safe
This is not currently possible with functions that take a
delegate parameter, including opApply. (without sacrificing
genericity)
A DIP could be made so that the function infers it&#
There are quite a few things in Phobos which can be improved
without much in-depth knowledge.
As these things get often forgotten and lost in the abyss, I
started a few GitHub projects:
- dip1000
- All high-level code should be usable in @safe
- Every Phobos symbol should be properly
t you can ignore @safe programming and
pretty much all of the annotations when writing quick & dirty
prototypes.
2. syntax matters
This has always been a focus with D, in that the syntax is
meant to be easy and familiar.
3. Incrementalism matters
This is the focus of -betterC, where
On 9/2/2017 1:03 PM, Paulo Pinto wrote:
Some of his ideas also apply to improving D's adoption among system devs.
Some interesting observations he made:
1. rigor is not wanted when prototyping
D recognizes this in that you can ignore @safe programming and pretty much all
of the annota
classical C devs at Microsoft, adopting a more
safe systems programming.
https://www.youtube.com/watch?v=EVm938gMWl0
Some of his ideas also apply to improving D's adoption among
system devs.
--
Paulo
Thanks for sharing this, looks quite interesting so far.
Hi everyone,
Videos of Rust Conf 2017 are now available, and Joe Duffy did the
closing keynote telling his experience developing Midori.
Specially relevant are the parts where he explains the internal
resistance from classical C devs at Microsoft, adopting a more
safe systems programming
On Saturday, 26 August 2017 at 02:19:53 UTC, bitwise wrote:
On Saturday, 26 August 2017 at 01:13:56 UTC, 12345swordy wrote:
On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote:
On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy
wrote:
[...]
How about actually answering the question
On Saturday, 26 August 2017 at 01:13:56 UTC, 12345swordy wrote:
On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote:
On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote:
[...]
How about actually answering the question instead of assuming
that I can't look up the definition of
On Friday, 25 August 2017 at 18:18:14 UTC, bitwise wrote:
On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote:
[...]
How about actually answering the question instead of assuming
that I can't look up the definition of any words?
While your statement may sound nice to you, and to s
On Thursday, 24 August 2017 at 14:59:05 UTC, 12345swordy wrote:
[...]
How about actually answering the question instead of assuming
that I can't look up the definition of any words?
While your statement may sound nice to you, and to some others in
this thread, that does not make it well-foun
On Thursday, 24 August 2017 at 01:38:50 UTC, bitwise wrote:
On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote:
On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:
[...]
Platitudes cause poor language design, not the completely
reasonable expectation of good tools.
And
On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote:
On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:
[...]
Platitudes cause poor language design, not the completely
reasonable expectation of good tools.
And who is "Platitude" here specifically?
http://lmgtfy.com/?q
On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote:
On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis
wrote:
[...]
[...]
There was a time that people
On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote:
On 22.08.2017 21:46, 12345swordy wrote:
On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis
wrote:
[...]
If you need an IDE to figure out what your code is doing,
On Tuesday, 22 August 2017 at 19:46:00 UTC, 12345swordy wrote:
On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis
wrote:
[...]
If you need an IDE to figure out what your code is doing,
that's an epic fail IMHO. Walter has mad
On Tuesday, 22 August 2017 at 19:56:46 UTC, Timon Gehr wrote:
I disagree with both the notion that this is poor language
design and that an IDE is required to make sense out of code
that uses the new feature.
Indeed, I can't imagine a DIP suggesting to make core regular
attributes, keyword li
On 22.08.2017 21:46, 12345swordy wrote:
On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis wrote:
[...]
If you need an IDE to figure out what your code is doing, that's an
epic fail IMHO. Walter has made similar statements on
On Tuesday, 22 August 2017 at 19:24:08 UTC, bitwise wrote:
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis
wrote:
[...]
If you need an IDE to figure out what your code is doing,
that's an epic fail IMHO. Walter has made similar statements
on several occasions.
There was a time t
On Tuesday, 22 August 2017 at 00:33:17 UTC, Jonathan M Davis
wrote:
[...]
If you need an IDE to figure out what your code is doing,
that's an epic fail IMHO. Walter has made similar statements on
several occasions.
There was a time that people would write code with even modest
performance re
On Tuesday, August 22, 2017 09:11:13 Steven Schveighoffer via Digitalmars-d
wrote:
> On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Regardless, it means that I would need to run a tool to figure out which
> > attributes actually applied to a function rather than just reading it
On 8/21/17 9:20 PM, Jonathan M Davis via Digitalmars-d wrote:
Regardless, it means that I would need to run a tool to figure out which
attributes actually applied to a function rather than just reading it like I
could do now. And the fact that this is can be done with UDAs right now is
_not_ a pl
Am Sun, 20 Aug 2017 00:29:11 +
schrieb Nicholas Wilson :
> On Saturday, 19 August 2017 at 17:10:54 UTC, bitwise wrote:
> > I'm still concerned about having to read code that's laced full
> > of custom attributes, the resolution of which may span several
> > files, templates, etc.
> >
> > I a
On Tuesday, 22 August 2017 at 01:20:13 UTC, Jonathan M Davis
wrote:
On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via
Digitalmars-d wrote:
That attributes are combinable and aliasable are nice side
effects of being regular attributes which in general are one
of the main foci of the DIP (
; > potentially have to go digging through other libraries just to
> > figure out whether a function is being marked with @safe or
> > not. You get some of that pain with any custom attribute, but
> > currently, the built-in attributes avoid it completely, and
> > being ab
arked with @safe or
not. You get some of that pain with any custom attribute, but
currently, the built-in attributes avoid it completely, and
being able to combine attributes makes it far worse, since then
you potentially have to go searching through a chain of
declarations to figure out
On Tuesday, August 22, 2017 00:21:16 bitwise via Digitalmars-d wrote:
> On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
> > you potentially have to go searching through a chain of
> > declarations to figure out which attributes are actually being
> > used.
>
> A good IDE should g
On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
you potentially have to go searching through a chain of
declarations to figure out which attributes are actually being
used.
A good IDE should give you this info if you hover over a
function. I realize D's tool support is sp
On Monday, August 21, 2017 10:41:49 Danni Coy via Digitalmars-d wrote:
> > For instance, as it stands, it's relatively easy to figure out whether
> > @safe
> > has been explicitly applied. You can look on the function and look for
> > @safe: or @safe {} which affect
> For instance, as it stands, it's relatively easy to figure out whether
> @safe
> has been explicitly applied. You can look on the function and look for
> @safe: or @safe {} which affects it. The same goes for other attributes.
> But
> as soon as you can do stuff like cre
On Sunday, 20 August 2017 at 01:33:00 UTC, Nicholas Wilson wrote:
I'm not quite sure how this would lead to a loss of modularity?
Not sure if modularity is exactly the right word. The problem
would be akin to extension methods in C#, or even a useful set of
UFC's in D.
So, imagine you dec
On Sunday, 20 August 2017 at 02:53:14 UTC, jmh530 wrote:
On Sunday, 20 August 2017 at 00:55:41 UTC, Nicholas Wilson
wrote:
Sorry, I was referring to preconfigurations in druntime like
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60
So modifying core.attrib
On Sunday, 20 August 2017 at 00:55:41 UTC, Nicholas Wilson wrote:
Sorry, I was referring to preconfigurations in druntime like
https://github.com/dlang/DIPs/pull/89/files#diff-26bf588c0174e6cd0fe3d4af615bebdaL60
So modifying core.attribute.defaultAttributeSet in the runtime is
the only way to
On Sunday, 20 August 2017 at 01:05:39 UTC, bitwise wrote:
This is indeed, a nice solution. I am a _bit_ worried about
abuse, and loss of modularity, but aside from that, I think
it's a better solution overall.
All features in the style of "I know what I'm doing, just let me
do it!" (=void, @t
101 - 200 of 1631 matches
Mail list logo
