# Generic-type-dependent static data

**URL:** <https://internals.rust-lang.org/t/generic-type-dependent-static-data/8602>\
**Category:** language design\
**Created:** [October 18, 2018, 3:05am UTC](https://internals.rust-lang.org/t/generic-type-dependent-static-data/8602 "2018-10-18T03:05:30Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![hanna-kruppe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/hanna-kruppe/32/6540_2.png) [@hanna-kruppe](https://internals.rust-lang.org/u/hanna-kruppe)\
**Post date:** [October 18, 2018, 5:04pm UTC](https://internals.rust-lang.org/t/generic-type-dependent-static-data/8602/7 "2018-10-18T17:04:56Z")

</div>

> [@stepancheg](#):
>
> I don’t see it as a significant issue. If C++ developers can live with these limitations of dynamic libraries, then Rust developers should be OK too.

In C++, there is at least a good way to link many separate libraries that need to share the static into a single DLL. The rustc `dylib` crate type can't be used in that way, and bundling crates into a `cdylib` library to achieve the sharing has the disadvantage that you have to define & expose a C ABI from it and `unsafe`ly interact with it from the rest of the application.

> [@stepancheg](#):
>
> Rust can emit a compile-time error if generic globals are used in dylib crate.

This incompatibility can lead to basically three different outcomes:

1. greatly inhibits adoption of generic statics (because it breaks clients of your libraries; and if this is a concern then using generic statics _internally_ in your library becomes a semver-breaking change)
2. effectively kill the remaining uses of `dylib` because they can't use a large portion of the ecosystem
3. a middle way, splitting the ecosystem into code that (transitively) uses generic statics and code that is compatible with `dylib`

The first and last option are clearly pretty bad outcomes. I wouldn't mind killing `dylib`, but if one wants to go that route then one should be honest about it and formally gather consensus to really kill `dylib` _as well as_ hypothetical future ways to build Rust applications that involve any sort of transparent dynamic linking.

---

_[View the full topic](https://internals.rust-lang.org/t/generic-type-dependent-static-data/8602)._