www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Possible change to symbol protection

reply bauss <jj_1337 live.dk> writes:
I believe it would be nice if we were allowed to pass symbols we 
don't have access to into templates, but of course we shouldn't 
be allowed to use them.

Ex.

foo.d

```
module foo;

private int bar;
```

baz.d
```
template MyTemplate(alias Symbol)
{
     ...
}

...

import foo;

MyTemplate!bar; // Okay, because we're not actually using bar 
within MyTemplate

...

template MyOtherTemplate(alias Symbol)
{
     enum MyOtherTemplate = Symbol;
}

MyOtherTemplate!bar; // Not okay, because we're using the symbol 
when we don't have access to it.
```

This would allow something like this:

```
template isVisible(alias Symbol)
{
     enum isVisible = __traits(compiles, Symbol);
}

...

static if (isVisible!bar)
{
     // bar is visible ...
}
else
{
     // bar is not visible ...
}
```

Instead of today you have to either do:

```
static if (__traits(compiles, bar))
{
     // bar is visible ...
}
else
{
     // bar is not visible ...
}
```

IMO that isn't pretty code and being able to have a template like 
"isVisible" would be much cleaner.

You can have a template like it, but it's really ugly, because it 
has to retrieve a string equivalent to the symbol name, which 
isn't typesafe at all.

```
template isVisible(string Symbol)
{
	enum isVisible = __traits(compiles, mixin(Symbol));
}

...

static if (isVisible!"bar")
{
     // bar is visible ...
}
else
{
     // bar is not visible ...
}
```
Nov 07
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, November 08, 2017 02:52:14 bauss via Digitalmars-d wrote:
 I believe it would be nice if we were allowed to pass symbols we
 don't have access to into templates, but of course we shouldn't
 be allowed to use them.

 Ex.

 foo.d

 ```
 module foo;

 private int bar;
 ```

 baz.d
 ```
 template MyTemplate(alias Symbol)
 {
      ...
 }

 ...

 import foo;

 MyTemplate!bar; // Okay, because we're not actually using bar
 within MyTemplate

 ...

 template MyOtherTemplate(alias Symbol)
 {
      enum MyOtherTemplate = Symbol;
 }

 MyOtherTemplate!bar; // Not okay, because we're using the symbol
 when we don't have access to it.
 ```

 This would allow something like this:

 ```
 template isVisible(alias Symbol)
 {
      enum isVisible = __traits(compiles, Symbol);
 }

 ...

 static if (isVisible!bar)
 {
      // bar is visible ...
 }
 else
 {
      // bar is not visible ...
 }
 ```

 Instead of today you have to either do:

 ```
 static if (__traits(compiles, bar))
 {
      // bar is visible ...
 }
 else
 {
      // bar is not visible ...
 }
 ```

 IMO that isn't pretty code and being able to have a template like
 "isVisible" would be much cleaner.

 You can have a template like it, but it's really ugly, because it
 has to retrieve a string equivalent to the symbol name, which
 isn't typesafe at all.

 ```
 template isVisible(string Symbol)
 {
   enum isVisible = __traits(compiles, mixin(Symbol));
 }

 ...

 static if (isVisible!"bar")
 {
      // bar is visible ...
 }
 else
 {
      // bar is not visible ...
 }
 ```
Honestly, I'm inclined to think that the way things should work is that if you pass a symbol to an alias parameter, then the access level checks are done only at the instantiation site and not within the template. That way, you can pass private functions to functions like find. The current behavior just seems like an unnecessary restriction, and having that restriction lifted seems a lot more useful than avoiding explicit uses of __traits(compiles, ...). - Jonathan M Davis
Nov 07