digitalmars.D - Public Private members?
- Flying-Toast (12/12) Apr 15 2019 I am not sure if this is a bug or if there is some explanation
- bauss (2/14) Apr 15 2019 I would argue that it's indeed a bug.
- rikki cattermole (9/27) Apr 15 2019 I would argue that it is not a bug.
- Adam D. Ruppe (5/6) Apr 15 2019 Yes, I agree. A specific attribute should override a group
- H. S. Teoh (8/26) Apr 15 2019 It's a feature. (Though one that I would rather term as a misfeature,
- bauss (3/28) Apr 16 2019 The feature would have been much more useful if you could do it
- Jonathan M Davis (25/61) Apr 18 2019 It's a useful feature in general, but it's definitely true that the
I am not sure if this is a bug or if there is some explanation
for this behavior, but either way it is confusing and I think it
should cause an Error.
---
class A {
private {
public int a;//No Error???
}
private public string s;//Error, expected
}
---
https://run.dlang.io/is/odJDnA
Apr 15 2019
On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:
I am not sure if this is a bug or if there is some explanation
for this behavior, but either way it is confusing and I think
it should cause an Error.
---
class A {
private {
public int a;//No Error???
}
private public string s;//Error, expected
}
---
https://run.dlang.io/is/odJDnA
I would argue that it's indeed a bug.
Apr 15 2019
On 16/04/2019 5:56 AM, bauss wrote:On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:I would argue that it is not a bug. If it is a bug, then this snippet is also a bug: struct Foo { private: int a; public: int b; }I am not sure if this is a bug or if there is some explanation for this behavior, but either way it is confusing and I think it should cause an Error. --- class A { private { public int a;//No Error??? } private public string s;//Error, expected } --- https://run.dlang.io/is/odJDnAI would argue that it's indeed a bug.
Apr 15 2019
Adam D. Ruppe <destructionator gmail.com> On Monday, 15 April 2019 at 17:59:16 UTC, rikki cattermole wrote:I would argue that it is not a bug.Yes, I agree. A specific attribute should override a group attribute. It is kinda nice for a big block of generally public stuff to have an exception to the rule.
Apr 15 2019
On Mon, Apr 15, 2019 at 05:56:31PM +0000, bauss via Digitalmars-d wrote:On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:It's a feature. (Though one that I would rather term as a misfeature, since it makes code needlessly hard to read.) The main purpose is to allow you to countermand the 'private' inside a large block of private members. T -- It's bad luck to be superstitious. -- YHLI am not sure if this is a bug or if there is some explanation for this behavior, but either way it is confusing and I think it should cause an Error. --- class A { private { public int a;//No Error??? } private public string s;//Error, expected } --- https://run.dlang.io/is/odJDnAI would argue that it's indeed a bug.
Apr 15 2019
On Monday, 15 April 2019 at 19:10:16 UTC, H. S. Teoh wrote:On Mon, Apr 15, 2019 at 05:56:31PM +0000, bauss via Digitalmars-d wrote:The feature would have been much more useful if you could do it with final tbh.On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:It's a feature. (Though one that I would rather term as a misfeature, since it makes code needlessly hard to read.) The main purpose is to allow you to countermand the 'private' inside a large block of private members. TI am not sure if this is a bug or if there is some explanation for this behavior, but either way it is confusing and I think it should cause an Error. --- class A { private { public int a;//No Error??? } private public string s;//Error, expected } --- https://run.dlang.io/is/odJDnAI would argue that it's indeed a bug.
Apr 16 2019
On Tuesday, April 16, 2019 10:45:52 PM MDT bauss via Digitalmars-d wrote:On Monday, 15 April 2019 at 19:10:16 UTC, H. S. Teoh wrote:It's a useful feature in general, but it's definitely true that the inability to negate various attributes limits its usefulness, and that's been brought up quite a lot over the years. A good DIP that provided a clean way to negate all attributes would probably be accepted. One problem I do find with this sort of practice though is that when people start dong stuff like safe: at the top of a file or or type declaration and then negate it with system or trusted on specific functions, it becomes very easy to think that attributes aren't applied when they actually are. It also doesn't work well with templates, because we don't have a way to indicate that they should use attribute inference for a particular attribute instead of using the attribute that was mass-applied to the file or type. So, personally, I mostly avoid using : or {} with attributes. The main exception would be public/private/protected, but even that has caused problems sometimes when other people have worked on my code, because they don't realize that a particular access level was already applied. So, while I definitely think that we should improve our ability to negate attributes and indicate that an attribute is inferred when it was mass-applied, I am afraid that it would lead to people mass-applying attributes in ways that would lead to maintenance problems that wouldn't exist if the attributes were just applied explicitly to each function. Most people don't like having to apply all of those attributes though. - Jonathan M DavisOn Mon, Apr 15, 2019 at 05:56:31PM +0000, bauss via Digitalmars-d wrote:The feature would have been much more useful if you could do it with final tbh.On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:It's a feature. (Though one that I would rather term as a misfeature, since it makes code needlessly hard to read.) The main purpose is to allow you to countermand the 'private' inside a large block of private members. TI am not sure if this is a bug or if there is some explanation for this behavior, but either way it is confusing and I think it should cause an Error. --- class A { private { public int a;//No Error??? } private public string s;//Error, expected } --- https://run.dlang.io/is/odJDnAI would argue that it's indeed a bug.
Apr 18 2019