On Sunday, 4 September 2016 at 08:57:15 UTC, Martin Nowak wrote:
On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
There are enough ways to leak access to private entity (alias,
template argument, taking address, some compile-time
introspection) to make such optimizations
On Sunday, 4 September 2016 at 08:57:15 UTC, Martin Nowak wrote:
On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
There are enough ways to leak access to private entity (alias,
template argument, taking address, some compile-time
introspection) to make such optimizations
On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
There are enough ways to leak access to private entity (alias,
template argument, taking address, some compile-time
introspection) to make such optimizations impossible without
extensive program analysis.
OK, anything else that
On Saturday, 3 September 2016 at 18:06:37 UTC, Dicebot wrote:
On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak
wrote:
On Wednesday, 31 August 2016 at 09:56:17 UTC, Johan Engelen
wrote:
(I can only think of complicated stuff that requires pretty
much whole-program analysis to prove
On 2016-09-03 18:02, Martin Nowak wrote:
Why not just use `__traits(getAttributes, var.tupleof[0])`?
I've already updated my code to use the above. When I first implemented
it, it was not possible to use a "tupleof expression" as argument to
__traits(getAttributes).
--
/Jacob Carlborg
On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote:
Yes, it does help. As private prevents usage outside of a
module it allows to do some optimizations that required whole
program analysis otherwise, e.g. variables and functions can
get internal linkage, thus reducing
On Wednesday, 31 August 2016 at 06:20:46 UTC, Jacob Carlborg
wrote:
Class/struct fields are accessible using .tupleof. I was using
__traits(getAttributes) in my serialization library to get
UDA's for these fields, including private ones.
Which is a weird implementation, b/c there is no direct
On Wednesday, 31 August 2016 at 09:56:17 UTC, Johan Engelen wrote:
(I can only think of complicated stuff that requires pretty
much whole-program analysis to prove validity, and in that case
adding `private` doesn't help any more)
Yes, it does help. As private prevents usage outside of a
On Friday, 2 September 2016 at 10:29:41 UTC, David Nadlinger
wrote:
On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe*
things (declaring that @trusted in the end).
On Fri, 02 Sep 2016 09:40:56 +, ketmar wrote:
> On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
>> On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
>>> std.traits wrappers should use __traits to build *safe* things
>>> (declaring that @trusted in the end).
>>
>> This
On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe* things
(declaring that @trusted in the end).
This has nothing to do with memory safety.
Actually it does, albeit
On Fri, Sep 2, 2016 at 10:15 AM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Friday, 2 September 2016 at 07:46:30 UTC, Rory McGuire wrote:
> actually, from my PoV solution is supereasy: just remove ALL visibility
> restrictions for traits. and i mean all.
On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe* things
(declaring that @trusted in the end).
This has nothing to do with memory safety.
i wonder who told you that
On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe* things
(declaring that @trusted in the end).
This has nothing to do with memory safety. It's just that
protection attributes were invented for OOP and when applied to
template
On Friday, 2 September 2016 at 07:46:30 UTC, Rory McGuire wrote:
actually, from my PoV solution is supereasy: just remove ALL
visibility restrictions for traits. and i mean all. allMembers
should return all members, getMember should allow to access *any*
existing member without annoying
On Fri, Sep 2, 2016 at 8:47 AM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Friday, 2 September 2016 at 06:27:11 UTC, Rory McGuire wrote:
>
>> Perhaps @system code should just completely ignore privacy?
>>
>
> it is uncontrollable. imagine attribute
On Friday, 2 September 2016 at 06:27:11 UTC, Rory McGuire wrote:
Perhaps @system code should just completely ignore privacy?
it is uncontrollable. imagine attribute inference: today, your
function was inferred @system, and it sees everything. and
tomorrow you fixed some other things, and now
On 02 Sep 2016 07:40, "ketmar via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
>>
>> Allowing access to private members has a lot of implications, e.g.
breaks lots of optimizations b/c you can't know who
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications,
e.g. breaks lots of optimizations b/c you can't know who
accesses sth.
i really HATE modern trend of turning tables. am i the only one
who thinks that the machine was
On Thursday, 1 September 2016 at 20:46:50 UTC, Steven
Schveighoffer wrote:
On 8/31/16 5:56 AM, Johan Engelen wrote:
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications,
e.g.
breaks lots of optimizations b/c you can't
On 8/31/16 5:56 AM, Johan Engelen wrote:
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications, e.g.
breaks lots of optimizations b/c you can't know who accesses sth.
"lots of optimizations"
Can you mention a few?
I'm
On 08/31/2016 02:08 AM, Martin Nowak wrote:
> On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
>> I'm a bit sad to see that
>> https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored
>> to fix issue 15907. Another decision could have been to break the
>> visibility for
On 2016-08-31 15:51, Chris Wright wrote:
And `instance_variable_get` in Ruby.
Or "send", "instance_eval" and so on. In Ruby it's more of a comment,
"please do call this method directly" :)
--
/Jacob Carlborg
On Wed, 31 Aug 2016 08:22:31 +0200, Jacob Carlborg wrote:
> On 2016-08-31 02:04, Ali Çehreli wrote:
>
>> P.S. While I'm on my soapbox, I've started to think private is
>> overrated anyway. A system language should allow to bypass that
>> protection. private should be a recommendation only.
>
>
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
Allowing access to private members has a lot of implications,
e.g. breaks lots of optimizations b/c you can't know who
accesses sth.
"lots of optimizations"
Can you mention a few?
(I can only think of complicated stuff that
On 2016-08-31 08:20, Jacob Carlborg wrote:
Class/struct fields are accessible using .tupleof. I was using
__traits(getAttributes) in my serialization library to get UDA's for
these fields, including private ones.
I think this was introduced already in 2.071.0.
--
/Jacob Carlborg
On 2016-08-31 01:08, Martin Nowak wrote:
Well there was reasoning to choose that solution instead of the other
(https://github.com/dlang/dmd/pull/6078) and the fact that private
members aren't accessible (set/get) is a good indication that nobody
needs this.
Adding an unsafe facility to access
On 2016-08-31 02:04, Ali Çehreli wrote:
P.S. While I'm on my soapbox, I've started to think private is overrated
anyway. A system language should allow to bypass that protection.
private should be a recommendation only.
I agree. Let private stop you from access symbols though the regular
On 2016-08-31 01:08, Martin Nowak wrote:
Well there was reasoning to choose that solution instead of the other
(https://github.com/dlang/dmd/pull/6078) and the fact that private
members aren't accessible (set/get) is a good indication that nobody
needs this.
Class/struct fields are accessible
On Wednesday, 31 August 2016 at 05:23:34 UTC, ketmar wrote:
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
As in needs private members in __traits(allMembers).
and in the end it just producing excessive noise in common
loops that does `is(typeof(__traits(getMember, ...)))`.
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote:
As in needs private members in __traits(allMembers).
and in the end it just producing excessive noise in common loops
that does `is(typeof(__traits(getMember, ...)))`. it would be
better to either leave that alone and allow all
On 08/30/2016 04:54 PM, Martin Nowak wrote:
> On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote:
>> On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
>>> I'm a bit sad to see that
>>> https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored
>>> to fix issue
On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote:
On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
I'm a bit sad to see that
https://issues.dlang.org/show_bug.cgi?id=15371 was completely
ignored to fix issue 15907. Another decision could have been
to break the
On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote:
On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
I'm a bit sad to see that
https://issues.dlang.org/show_bug.cgi?id=15371 was completely
ignored to fix issue 15907. Another decision could have been
to break the
On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote:
I'm a bit sad to see that
https://issues.dlang.org/show_bug.cgi?id=15371 was completely
ignored to fix issue 15907. Another decision could have been to
break the visibility for the traits allMember, getMember,
derivedMember and
On 08/30/2016 02:58 PM, Basile B. wrote:
On Tuesday, 30 August 2016 at 19:37:25 UTC, Martin Nowak wrote:
Third beta for the 2.071.2 release.
This beta fixes spurious deprecation warnings with templates using
getMember (Issue 15907), please read the changelog for more details.
On Tuesday, 30 August 2016 at 19:37:25 UTC, Martin Nowak wrote:
Third beta for the 2.071.2 release.
This beta fixes spurious deprecation warnings with templates
using getMember (Issue 15907), please read the changelog for
more details.
http://dlang.org/changelog/2.071.2.html
Third beta for the 2.071.2 release.
This beta fixes spurious deprecation warnings with templates
using getMember (Issue 15907), please read the changelog for more
details.
http://dlang.org/changelog/2.071.2.html
http://dlang.org/download.html#dmd_beta
Please report any bugs at
38 matches
Mail list logo
