On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote:
https://github.com/NightmareX1337/DX
Don't kill me, I'm just trying to help...
You can report issues and create pull requests :)
Destroy!
- Your point against undisciplined UFCS: Completely agree.
I'm writing a 'DIP' that I'm probably never gonna submit to add
"extension interfaces" (my syntax ATM is leaning towards "alias
class/interface") that add callable-with-method-syntax free
functions in a way that they're treated as native parts of the
supporting type (one case: when passing the type name into a
foreign template they're picked up as if they were methods
instead of being out-of-scope).
In a (very big) way, they're stolen whole-sale and are being
adopted to fit from Rust's traits.
- Null-coalescing operator: No. Pattern matching and a
`std.typecons.Option(T)` would do better IMHO and are more
general.
- I've stayed away from UDAs but your points make me finally want
to stay away a bit more. (except for a small side project but,
well, necessities)
- Managed~unManaged pointers: needlessly complicated. Just
provide a non-GC 'new'. What wouldn't that solve as well as your
`type*` vs `type^` pointers? (btw, `^` wouldn't conflict with the
xor-operator as I understand it. `!` is already used both as a
unary prefix and binary infix operator).
- Not sure about `alias this`/`opCast`. I just use `opDispatch`
whenever I need something more complicated than alias this (not
much at all).
- I VERY strongly believe in the inherent superiority of
kebab-case compared to CamelCase and snake_case. KEBAB-CASE FOR
PRESIDENT!
- I hated D's module system at first. I still hate that I have to
create separate files just to have a small internal
namespace-separation. But I like being able to just go find
something in a file in a project based on its compile-time path
(granted, good design should enforce this but...). I dunno; on a
fence about it.
- `__traits(callerName) & __traits(callerChain) &
__traits(callerPath)`: I want a `__traits(instanceContext,
symbol)` that returns an alias allowing me to access all
compile-time info on surrounding symbols to the passed one (which
are local to the /instance/ so include imported names and local
types and such). That would solve SO MANY THINGS with template
adventures. Not sure on what it'd make worse, though.
- Partial lock for arrays: Sounds complicated for D's current
analysis abilities. But sounds cool.
- pragma(inline): ABSOLUTELY. The idea that `pragma(inline)`
verbatim tells the compiler precisely nothing hurts my OCD so
much.
- Old attributes got a space in the keyword list. There were
proposals to shift them all to `@` syntax but it stalled early on.
- Runtime reflection: Hmmm... Runtime UDA's sound suspiciously
like a type-state system. Complicated, interesting.
- Templates are obvious enough as they are IMHO.
- Friend classes: Um, maybe make a separate MyTypeImpl
struct/class that takes a MyType instance and initializes itself
with a pointer and through it you can access all the private
stuff you want? (MyTypeImpl would be in the same module as
MyType, of course.)
Good stuff ;)
