Why is this allowed? Inheritance variable shadowing

a11e99z black80 at bk.ru
Tue Aug 13 07:07:15 UTC 2019


On Tuesday, 13 August 2019 at 06:39:24 UTC, a11e99z wrote:
> On Tuesday, 13 August 2019 at 05:57:23 UTC, Mike Parker wrote:
>> On Tuesday, 13 August 2019 at 04:40:53 UTC, Chris Katko wrote:
>
> OT:
> and again how to easy to google info about error/warning just 
> with one word "CS0108"

D can use attrs for such things.

OT:
1) need to add compiler attrs that speaks with compiler - they 
are change code generation, compiler passes or something. like 
pragmas do.
2) need to separate all attrs in a separate construction like C# 
do
> [inline, nextOne, returns: someAttrToReturnValue]
> int meth( [argAttrCanBeToo] int x ) { }
or
> [hide]
> public int x = 2;
cuz its visually separated and easy to skip it with eye when u 
reading/reviewing code.

it can be mess for now:
> pure @trusted int meth( int x ) @nogc nothrow { return 5; }
NB all of this attrs is compiler attrs not user, they changes 
compilation.
- no possibility add attr to args or returns
- some attrs with "@" and some don't
- its hard to read when D adds 2-3 attrs more for next 5-10 years

my wishlist of new compilation attrs:
- [hiding] for subj
- [offset(N)] for explicit struct alignment without mess with 
unions/align(4) cuz sometimes I know exactly offset for field and 
I can point it with no side effects calcs adding pads, unions and 
etc
- [inline(bool)] instead of pragma( inline, true ) that looks 
like compiler attr but another way
- [deprecated(text)]
- [nodiscard] cannot discard return value
- etc


More information about the Digitalmars-d-learn mailing list